[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

Alex Schultz wrote:
>>   The question is what goes into the stable branch.  By its nature, everything 
>> has to go into the head branch (presuming the change is still applicable).  But 
>> the scope of changes for the minor releases in the stable branch probably 
>> shouldn't be too big.
>>   
> Personally, I think things to go into the stable branch, are of course
> things we want in minor releases, and in my opinion, that should be
> bugfixes, and features that are not large/extensive. Of course, then the
> difficulty is in defining how large or extensive makes it worth putting
> in for the next major release, and that I believe needs to be decided in
> a case-by-case basis.

  And trying to define what large of extensive may need some clarification.

  Some of it may just really boil down to what the developer doing the fix in 
the head wants to do, unless we put requirements that features within some scope 
must also be in the stable release.

  For example, I go off and add some new feature to the head branch, but because 
I'm lazy, don't put it in the stable branch.  Thus that feature is only in the head.

  someone else could port over that change to the stable release if they really 
want it.

  However, as I think about, you probably want these features in the stable 
branch just so they get more use (and thus may find the bugs that can then be 
fixed in the head branch).

  But even that can be error prone - I make some minor enhancement which seems 
like it would be fine for the stable release, but it actually makes use of some 
new feature not found in the stable release, so that feature then also has to 
get ported over, etc.  This probably isn't an issue, but when we are talking 
about doing major things to the head release, may not be as uncommon (looking 
back at the 1.x releases, think about things like the skill/spell redo and 
key/value lists - there are many minor changes that have been made since that 
code was committed that requires it).


> Personally I would rather dislike that setup, though I don't believe
> that is what he is trying to say. What I think he is trying to say is
> more like:
> 
> 2.0 release.
> branch for 2.1 is made based on 2.0
> 2.1 is release, branch for 2.2 made based on 2.1
> 2.2 is release, branch for 2.3 made based on 2.2
> 
> That said, I don't see how that would end up much different from just a
> branch for each major release, unless we plan on providing bugfix
> releases for older releases, which I personally don't see a need to do.

  Even if we are providing bug fixes, I think it would still be better to branch 
the stable release for those micro releases then branch the stable for each minor.

  The other problem with the above scheme is you start getting crazy version 
numbers in files, as each time you do a branch, if you commit/change a file, you 
get a couple more decimals placed.  So under that scheme, by the time you get to 
2.9, you could have files with versions like '1.9.2.5.2.7.1.12.2.23.1.6.2'.

  I think it is much better, and much more common practice for branches to be 
based on the smaller pieces, and the main branch/head to be where most of the 
changes are being made.