Re: Repository and release numbering changes

Grzegorz B. Prokopski wrote:

> Changes proposed:
> 1. staging becomes trunk, bugfree disappears (so we only have trunk),
> 2. "branches" directory becomes writable for all developers,
> 3. releases will basically use two-number versions ie. 1.10, with
>    possibility of making "bugfix" releases ie. 1.10.1 when necessary.
> 
> Comments?

My biggest request is that the new trunk keep the same history as 
staging, so that I can easily merge the diff between the last time I 
updated to staging (about 1.1.9) and some arbitrary revision in the future.

The problem that exists for me with current development is that there's 
no backporting of bugfixes to stable branches, and so if you update / 
merge to the latest and greatest, you end up with a bunch of new stuff 
as well as a bunch of bugfixes.

It would be nice to get just the bugfixes, if that's all that you want. 
  I personally always get bitten by stuff I don't care about when I 
update, but I do the updates anyway because I want the fixes.  Trying to 
find and merge the fixes myself just isn't feasible.

I think what I'm suggesting would be something like the GCC versioning 
system / development model (x.y.z, x is major version number, y is minor 
version number, z is fixes developed in the highest y (read: 
experimental / moderately unstable new stuff) that get backported to all 
y's since the highest x).  Is this too much work for you to manage?

However, ultimately, if you and Etienne and David definitely think some 
new model is a good idea, then I think it's a good idea.  You're the 
ones with the most experience managing branches and releases, and you're 
the ones who continue to deal with that daily.

Cheers,
Chris