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 _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
