19 Feb
2014
19 Feb
'14
2:11 p.m.
On 02/17/2014 10:11 PM, Nicolás Reynolds wrote:
Gioacchino Mazzurco <gio(a)eigenlab.org> writes:
Really nice Nicolas, thanks!
i've adopted it without effort, and it helped me keep things tidy
i've back-tagged the two de-facto "releases" we had last year, (IS4CWN
demo and hackgaraiak incidental mesh) and started a simple
release-tagging scheme
X.Y where X is major version bump, and Y is incremented with each hotfix
branch merge.
we might change that in the future (i'd love to see a v1.0 ;) ) but i
think it works for now.
With gio we have agreed on IRC to follow the nvie.com guidelines (either
manually and/or using git-flow)
and after tidying up a little bit of the past mess, we're working on our
own feature branches already succesfully
https://github.com/libre-mesh/lime-packages/branches
the convention adopted is exactly what's outlined at nvie.com (including
branch naming)
so master is normally untouched, every commit/merge there means a
release, and requires tested working code
and develop (or more likely, feature branches based off develop) is
where daily commits happen.
git clone https://github.com/libre-mesh/lime-packages/
should give you the last "stable" release
and
git clone -b develop https://github.com/libre-mesh/lime-packages/
should give you a more recent, maybe broken version.
cheers!
guit
On Monday 17 February 2014 17:33:15 Gioacchino
Mazzurco wrote:
hi, we have been using gitflow[0] with good results, and it also allows
publishing feature branches :) keeping those branch in origin and WELL UPDATED
If I wasn't enough clear, I mean that each of us should push as soon as have
something committed (I usually push for each commit i do), to make easier to
follow what is happening to the others :)