[Olsr-dev] A last question about the new repository design

[Hans-Christoph Steiner]

On Aug 14, 2012, at 3:37 AM, Ferry Huberts wrote:

> On 14-08-12 09:15, Henning Rogge wrote:
>> Hi,
>> 
>> I am thinking about what to do with the "stable" branch at the moment.
>> 
> 
> There is no need for 'stable' in the new process.
> 
> We'll just have master, tags on releases, and maintenance branches.

I agree.  This makes a lot of sense and mirrors the current development process


> Oh, and maybe some feature branches off off master for some bigger features.

I propose that the main repo only consist of the 'master' and release branches.  For all other dev branches, they can go in other repos, like people's personal repos on sourceforge, github, or wherever.  That keeps the main repo clean and readable and allows people to do whatever they see necessary when working outside of master and release branches.  git makes this easy to do, so we should take advantage of that.


>> Our new model calls for a branch for each release where we stabilize the
>> release. Maybe we will even keep some of this branches to support
>> bugfixes for releases that need to be maintained longer (e.g. versions
>> that go into Debian).
>> 
>> So we will have branches called "stable_0.6.4" and similar.
> 
> 
> Just call them v0.6.4 etc. much easier.
> And use tags like 0.6.4.x on those branches

I like the general idea, but recommend a little more verbosity so that the tags and branches are self-documenting.  Either 0.6.4 or v0.6.4 as the release tags works well, then the branches could be like release-0.6.4 or something like that to mark that branch's purpose: working towards a release.


>> The model works well I think, it just does not contain a good way to get
>> the "most recent stable" automatically.
> 
> Why is that needed?
> I've never seen a project that needed that

I have seen projects that do that, but they have more elaborate workflows that olsrd.  In olsrd, the most recent stable would be the most recent release tag.  That's how people are working now, so why not just make the git reflect that?


>> I see two options how to deal with this.
>> 
>> The easiest one would be to use the "stable" branch to track the most
>> recent release. Every time we tag a release, we merge it to "stable" so
> 
> I would not advise this.
> Maintenance branches are there for a purpose. We only fix critical bugs on those and we do want to keep them completely seperate from other branches. No need to merge them into any other branch. Maintenance branches and master will diverge, sometimes significantly.
> 
> We just need to pay attention to fixes on maintenance branches and see if we need to cherry-pick them over to master (and visa versa)
> 
>> automatic scripts can easily grab this tagged (and signed) version.
>> Still, this means a lot of "unnecessary" merges.
>> 
>> A second option would be NOT to use a new branch for every release but
>> always to use the "stable" branch for stabilization. This would mean we
>> just merge "master" into "stable" every times we start a new release. I
>> don't like this, because we loose the ability to differentiate between
>> the releases easily.
> 
> Don't use stable. Too confusing. Just use version tags and branches.
> 
> Declaring a feature freeze can work on master since we are a small team.
> You could also do that by branching and stabilizing on the branch, it's a matter of taste.
> 
> The latter allows development to continue independent (and parallel to) stabilization.
> 
>> 
>> Third option would be to just drop the "stable" branch.
> 
> yes please

I completely agree, just drop the 'stable' branch entirely.

.hc