[crossfire] 2.0 release, was Re: Code restructuring

[Alex Schultz]

Mark Wedel wrote:
>   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.
>   
Agreed, I was just nitpicking about what would be the ideal
circumstances, and if someone does have code ready right after a major
release, it should indeed still be committed. Personally I think this
difficulty would be perfectly fine to live with, provided that those who
do the restructuring make sure they keep detailed logs of what
functionality of the code moved where in the changelog (i.e. along the
lines of "Moved weapon behavior from apply_ob() in item.c to
type_weapon_apply() in types/weapons.c"), to make it easier to people to
deal with.

>
>   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).
Agreed, I was just pointing out that even with major releases, we should
think before breaking things, and if there is a reasonable way to get
things done, without breaking, or without making the code messy, etc.
then it should be considered.

Alex Schultz