[lime-dev] About branching strategy: adopted nvie model

Gui Iribarren 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[0] 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 
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

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

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 mailing list