[lime-dev] About branching strategy: adopted nvie model
gui at altermundi.net
Wed Feb 19 14:11:55 UTC 2014
On 02/17/2014 10:11 PM, Nicolás Reynolds wrote:
> Gioacchino Mazzurco <gio at eigenlab.org> writes:
>> On Monday 17 February 2014 17:33:15 Gioacchino Mazzurco wrote:
>>> 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 :)
> hi, we have been using gitflow with good results, and it also allows
> publishing feature branches :)
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
X.Y where X is major version bump, and Y is incremented with each hotfix
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
the convention adopted is exactly what's outlined at nvie.com (including
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
git clone -b develop https://github.com/libre-mesh/lime-packages/
should give you a more recent, maybe broken version.
More information about the lime-dev