[crossfire] 2.0 release, was Re: Code restructuring

[Yann Chachkoff]

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 
each point will solve current problems. Then we need to define working 
groups, and only then shall we be able to get a realistic deadline.

Currently, we only have a list of proposals - that's a good start, but I think 
that a clear organization of the work is required if we want to get things 
done in a timely fashion.

>   I'd also say that generally speaking, any of these big changes needs to
> be completed at least a month before the targeted release date, simply so
> there is sufficient time to find bugs, make fixes, then run the fixed code
> to see if it works, etc.
>
>   The end of the year date for next release was somewhat arbitrarily
> chosen, but some date is needed.
>
Again, I think that we cannot define a date before having clearly defined and 
organized the work - and there's still a lot to do in that respect, IMHO.