module revision "standard"
micke.l...@hotmail.com
I'm wondering about the way to handle module version with GIT-Hub in
such a way that it becomes easy to integrate in the XDE.
With the .zip is was "easy". You just downloaded everything again.
As an example I pushed this to GIT
https://github.com/lilltroll77
What is my correct move when I wish to release a new. rev in such a
way that it get's easy for the other users, and not ending up in
strange path's in the makefile ?
Should I always continue on the existing project, renaming it, create
new resp. or how to do it ?
Al Wood
Zips should be considered binaries rather than source controlled
files. However Github does have a 'downloads' area/feature
which tends to be used for binary like releases such as zips and tars
etc.. You can also tag these to make them easier to find including
revision versions etc.. this seems like a common practice.
regards
Al
On 29 December 2010 13:18, micke.l...@hotmail.com
micke.l...@hotmail.com
So I clean the projects before I push it with GIT. That way only the
ASCII parts uploads to GIT resp.
We should agree of a solution where to place the stable "bin" releases
of modules - in this case the .zip that includes the projects.
Someone starting should be able to just import the modules as usual
like most new users would.
If he later wants to participate he can GIT is and the push the
changes to the owner of the resp. that can handle the updates.
Does the GIT handle the "todo" list and bug list ? or is that another
place?
Searching all forums regarding bug topics drives us mad. The same
questions comes up again and again and again, but you do not realise
it before someone answers you.
Like with the XMOS Ethernet. After a year I still do not have a clear
picture of the actual bugs, and if someone has fixed them. Is there a
package with a working xhttpd for an example ?
I checked how it was made in Ubuntu, it was very easy to read the bug
list and the progress about it, and the team committed to it.
On 30 Dec, 00:09, Al Wood <a...@folknology.com> wrote:
> Although I am no expert...
>
> Zips should be considered binaries rather than source controlled
> files. However Github does have a 'downloads' area/feature
> which tends to be used for binary like releases such as zips and tars
> etc.. You can also tag these to make them easier to find including
> revision versions etc.. this seems like a common practice.
>
> regards
> Al
>
Al Wood
<micke.l...@hotmail.com> wrote:
> OK, I made some changes.
>
> So I clean the projects before I push it with GIT. That way only the
> ASCII parts uploads to GIT resp.
> We should agree of a solution where to place the stable "bin" releases
> of modules - in this case the .zip that includes the projects.
>
naming to indicate revisions/releases. In some project other use 'bin'
directories to house the binaries this is another approach, I would
like to hear other's opinions on this matter over which way we go.
> Someone starting should be able to just import the modules as usual
> like most new users would.
> If he later wants to participate he can GIT is and the push the
> changes to the owner of the resp. that can handle the updates.
>
Yes we need to be able to magically assemble modules where possible.
do modules have there own project or are they sub projects. How to we
manage inter-releases etc.. can we link the modules automagically
perhaps?
> Does the GIT handle the "todo" list and bug list ? or is that another
> place?
>
Git hub has 'issues' which we should use for todo's and bugs, we can
use its labe function to mark the type of issue. it also has a search
function could be very will be handy. I think it also has voting but I
haven't actually used the issues function yet so can't comment on its
effectiveness.