[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

Alex Schultz wrote:
>
>>   But that can then lead to rapid turnover of major releases. Eg, I do major 
>> code restructure, make 3.0.0 release.  Then some other change is made (maybe 
>> compatibility breakage, maybe some other code restructure) - do you make a 4.0.0 
>> release 3 months later then?  I think there needs to be some minimum/maximum gap 
>> between major releases.
>>   
> This is true, however I can't see major code restructures working well
> as part of a minor release. What I see as ideal though, is if the trunk
> gets a few major features almost worthy of a major release, then a code
> restructure happens, and a release happens afterwards. Of course, timing
> may not work out so ideally, but perhaps it might be good for people to
> try to time their major code restructures to finish about just before
> when a major release is anticipated.

  Well, a major code restructure can't go into a minor release.  Under the 
proposed model, the only thing that comes from the main branch is major releases 
- when a major release is done, then a new stable branch is set up where the 
minor releases come from.

  Going back to the original issue is code drifting apart - if a major 
restructure is done in the main branch, it makes fixing any bugs in both the 
main and stable branch more difficult.

  It could just be we live with that difficulty.  Or if a major restructure is 
done shortly after a major release, still have to wait for the 6 months or 
whatever.  I don't really want to try to say 'major code restructures happen 
near the end of the cycle' - I think if someone has the code ready and it is on 
the list of things to do, it should be committed.


> Yes, this is true, however despite that, not all major releases need
> break things, and no sense breaking things unless there is a logical
> reason to.
> (random thought about old clients: There are a good number of people who
> still use the plain X client, the gnome client though, I don't think is
> in usage though I may be mistaken)

  However, as per gros's comment, there needs to be sufficient changes between 
the releases to warrant a major release.  We probably don't want to do a new 
major release if there are not any signficant changes - I suppose this may be a 
matter of opinion, but if we go in this model, I think that sort of needs to be 
the case, as otherwise we get into confusion at what each branch/release means.

  There can still certainly be major releases which don't break compatiblity in 
any way but still hold other significant changes (new features, or changing of 
existing features/expanding them).