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

[Ferry Huberts]

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.
Oh, and maybe some feature branches off off master for some bigger features.

> 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


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

>
> What do you think?

see above ;-)

>
> Henning Rogge
>
>

-- 
Ferry Huberts