Re: [crossfire] 2.0 release, was Re: Code restructuring
Le mercredi 19 juillet 2006 06:50, Mark Wedel a écrit : To me, the issue for targetting this for a 2.0 release is timing. We can come up with a huge list of things that should be done before a 2.0 list. And we could attempt to do them all, but then 2.0 probably won't be released for 5 years or the like. Although I do agree that delaying 2.0 too far away would be a bad thing, I also think that releasing a 2.0 that would basically be a 1.9 with some fixes would make little sense. The discussion for a 2.0 release probably needs to be done. Several questions need to be asked answered: 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. That's a question that can only be answered once goals to reach for 2.0 are cleared. 2) What are the 'must have', 'nice to have', and 'not really important' features to target for that release? The wiki - http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by high/medium/low priorities. Does code restructuring fall into high category? There is a code cleanup which is high, but I had envisioned that to be a bit more modest than what is being talked about now. I'd say that there are basically two types of changes to be done: (a) Fixes to problems currently encountered in the 1.9.x version of Crossfire. Typically, this is the case for Game balance or Fix weather. Those do not involve creating new systems, but rather work so that the current stuff does its job as expected; (b) Additions to the existing functionality. Two subtypes here: (1)minor changes, that are relatively easy to code, or that are mostly not necessary and (2)major changes, that will require some time to complete, or that change the game experience in a significant way. I'd say that everything that is (a) should be done and integrated as a release of the 1.x series - there is no reason to change the major version number for bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - major changes is what one expects to have when the major version number itself changes. Finally, for stuff belonging to (b.1), I'd say that it depends on the priority we put on it: if it is desperately wanted, then integrate into the 1.x series; if that's just a nice idea but not really top-priority, then push to 2.x. Depending on the timeframe would determine how many can really be done in the targeted time. I think that's a bit backward-thinking: the number of tasks should define the timeframe, not the opposite. Bugs, both new and current, also need to be similarly prioritized - fixing bugs is great to do, but can also be a big time sink. That's true, but I don't think it is realistic to start working on 2.0 when 1.x isn't even mostly bug-free. 3) Who commits to working on these changes? The wiki above has lots of things to do, but very people signed up to do them. If there are only a few people actively working on making code changes, that certainly limits number of changes that can be done for a release. So all that said, if we think end of the year is a reasonable target date, I think that limits us to trying to take on somewhere between 2-4 decent sized projects. If we look at the wiki, taking things currently marked as high, that would be: Character creation - new character creation method Sounds good for inclusion in 2.0 - new feature that's radically different from what we have. Game balance - fix various balance issues Looks like a bugfix to me rather than a new feature - so that's 1.x work, IMHO. improve client ui Depends on the level of improvements. If that's just fixing/completing the current client, mark that 1.x (that's basically nothing more than minor tweaks); if that involves rethinking the client UI, then mark that 2.0. code cleanup (but have to be careful this doesn't lead to rewriting huge sections of code) If that's only cleanup without any fundamental change in the way it works, then that's definitely an 1.x task. change password command Agree, although it looks like a rather minor point to me compared to others. Of which, none of those currently has anyone signed up to do them (I was personally planning to look at the character creation sometime soon) I'm not even sure there is a clear document for each of those tasks describing what we are supposed to add/do/design. I mean, everybody understands what new character creation method; but there is nothing documenting what has been decided about it, what it should/shouldn't contain, etc. That's basically a free for all: the first one that assigns itself to the task and submit it to the CVS will get its concept becoming the de-facto choice. I think that before starting to blindly code, we need to clearly define how
Re: [crossfire] 2.0 release, was Re: Code restructuring
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. 2) What are the 'must have', 'nice to have', and 'not really important' features to target for that release? The wiki - http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by high/medium/low priorities. Does code restructuring fall into high category? There is a code cleanup which is high, but I had envisioned that to be a bit more modest than what is being talked about now. Depending on the timeframe would determine how many can really be done in the targeted time. I think the real question is, how 'big' do we want 2.0 to be? How much justifies a major version number? The answer to that, affects what features we should target to have in 2.0, and that dictates the timeframe. At the same time though, the timeframe does affect the other parts, it isn't just a one way chain, as we have to also make sure the features are reasonable to complete within a reasonable timeframe. What it really is, is not a question of how much can be done in a timeframe, or how 'big' we want it. It is a matter of weighing how 'big' we want it, against what timeframe is reasonable. Balances are always so much harder to weigh than simple one way relationships ;) 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. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
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 crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
