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