Alex Schultz wrote: > Mark Wedel wrote: >> 1) What is the target date for a 2.0 release? It can't be 'when all the >> cool >> stuff is done', as then it never happens - always something new to add, etc >> - >> some general date has to targeted. I had previously mentioned shooting for >> end >> of this calendar year. >> > Well, I think that targeting a general date may not be the best > solution, and a better one would be having a feature-based target. > Essentially based upon the sort of things you talk about below. We just > need to limit the number of "must have" things to be reasonable and wait > till we have those, and a few "nice to have" things.
Have to be careful and limit the feature so that you don't keep adding more things to be done, to the point where nothing ever gets done. Whatever is targeted for 2.0, there will be things that should be done for 3.0, 4.0, etc. The next version can't hope to cover everything that should be done. > Another issue though, is due to the way that crossfire has released in > the past, releases with minor version number increments are a mixture of > bugfixes, minor features, and major features. One question is, what will > make the difference between 1.9 and 2.0 so different from 1.7 and 1.8? > Really, I don't see how anything that has happened or is planned for > 2.0, will really make the change so much bigger than the difference > between 1.7 and 1.8. For an even better example, the difference between > the releases where the skills system changed a bunch, is probably much > more worthy of a major version change, than what is currently planned > for 2.0 IMHO. Personally, the only way I can see things changing enough > in a single release to in my opinion warrant a 2.0, is if we start > keeping a "stable" branch in CVS and have that used for minor releases, > or if something either in code and/or gameplay undergoes a major (in a > loose sense) restructure. One thought is to define major.minor.micro releases like this: major release: Changes that break compatiblity (need to start with a clean server as player files are not compatible, server/client compatibility may be an issue, and/or programs removed (x11 client goes away for example). minor release: feature enhancements and bug fixes. micro release: only bug fixes. In terms of CVS, that could work out like: head branch: Contains major release - all changes (unless not applicable due to other changes) go in the head. stable branch: This is where minor/micro releases come from. When a new major release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I really only see one stable branch per major release - the determination of micro/minor is a call of the RE at time of release based on what changes. I think in this model, releases done on a fairly regular schedule (quarterly? Every 6 months) since the number of changes probably won't be that big. The question is then who is responsible for updating the stable branch. IS the developer who commits the change responsible? Do we have some people responsible for maintaining the stable branch and they make the call on what changes to pull out of the main? And you get that thorny issue - what level of enhancements from the main branch get put into the stable branch. While some may be obviously incompatible, there could be other ones which are pretty significant changes. Under this model, I don't think you want to go too long between making major releases - simply because as more time passes, the code from major and stable will drift farther and farther apart, making it harder and harder to take any fixes from the main branch to the stable branch - this then basically amounts to having two different programs to maintain (and/or the stable branch stops getting change as if I fix a bug in the head branch and can't easily see in the code where that belongs in the stable branch, I may not be inclined to get the stable branch, compile, spend the time to debug, etc to try and fix that problem). IMO, this CVS/release model actually is pretty good. The problem is how to handle the head/main CVS branch. It would seem that official releases are never made from it until the target for what constitutes the release is made. That may work if there are people running these CVS servers and clients. But the danger there is it can be hard to run a CVS server when a commit at any time could result in the entire server being reset - I think you almost need to set up various snapshots where you can say 'the code will be stable enough for at least some number of months' so people can feel somewhat comfortable playing on the server, etc. I think then also some form of filtering or a separate metaserver is needed so players do play on the appropriate server. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
