[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

Yann Chachkoff wrote:
> 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.

  At some level, all version numbers are arbitrary and can mean whatever.

  In my thinking, the differences of any major release should be seen from the 
previous major release (1.0 -> 2.0, 2.0 -> 3.0), not the previous minor release. 
  In which case a lot has changed from 1.0.

  Maybe that isn't great, but as I think was discussed elsewhere, if there is a 
separate branch for 2.0 (or 3.0 thinking after that), it probably won't get used 
much, and before you can really release it to the general public, you have to 
make sure it is in fact used.  So this means that a lot of those features have 
to put in to the previous version.

  Maybe going forward, there should be a pre-2.0 (or pre-3.0) branch, and all 
significant changes have to be put in that branch, so that current branch only 
contains bug fixes.  But this still goes back to what do the numbers really need 
- if most people are running pre 2.0 (pre-2.0-1.9?), then there are not lots of 
changes when that is decided to stop calling it pre 2.0 and make it as a real 
release.


> 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.

  That is a reasonable model - the official version is bug fix only, and all new 
features go into what will become the next major version.

  But as said above, snap shots/pre releases of the next major version still 
need to be done at some point, and what do we call those?  Sort of goes back to 
whatever arbitrary numbering scheme we choose.

> 
>> 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.

  Problem is that then we will never make another major release, as the list of 
things to do will continue to grow.

  And there is certainly the case of things that get deferred to the next 
release.  That happens all the time in all sorts of software - it would be nice 
to have feature X, but doing that means that things won't be completed for 
another 12 months, so will put feature X into the next version.

> 
>>   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.

  But there are many different types/layers of bugs.  Many bugs may fall more 
into the RFE category or nice to have feature type of thing.  And there may be 
many other bugs that fall more into the inconvenience of slightly annoying. 
Saying it should be 100% bug free is also one of those things that is likely to 
never happen (as you fix ones, new ones will always get filed).  Pretty much all 
software ships with some number of bugs.

<much snipped about specific things to do>

> 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'd say that the first person that steps in to the task then writes up what 
they think should be done, send it out, get comments, revise, repeat, then code 
when decided.

 > 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.

  I think that is a much better solution than some committee deciding what 
should be done and then expect someone else to write that code.  As in a 
volunteer project, I think we'd see a lot of specs and not a lot of code.

  And I think we have to be careful about making things too complicated. 
Crossfire doesn't have a huge developer base - the need for high degree of 
coordination, isn't as great as if there were 100 developers with many different 
major projects going on at once.

  In fact, I just looked over the server changelog - I may have miscounted, but 
I only counted 6 different people committing code (or at least code reflected in 
the changelog) since the start of the year.


> 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.

  So saying that, what I'd be tempted to say is the next process in this:

People have to take claim of these various big changes.  What this means is they 
are the main person responsible - they write up what will be done, get comments, 
figure out how long it will take, and then see through the process of making the 
changes (this doesn't necessarily mean doing all the work themselves if they can 
recruit other people to help out, but such a person is really the lead on that 
aspect)

  Things that don't get claimed get scratched off the list.  Lets face it - 
there are lots of things that would be nice to do.  However, if it is a feature 
that no one wants to do, it won't get done.