[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

Yann Chachkoff wrote:

>>   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.  
>>
> Sounds a somewhat flawed way of thinking. If you develop a new version of a 
> software - whatever the software is - you cannot expect it to be widely used 
> before it is released.

  The biggest danger is that given there are only a handful of servers, if the 
first release of 2.0 (or whatever major version) has serious problems, it might 
be hard convincing people to try 2.1, etc

  And if the changes break compatibility, that makes it even less likely for 
servers to switch over.


> I have the feeling that you consider that leaving the 1.x server for a 
> possibly long period of time without adding more than bugfixes to it is not 
> acceptable - but I personally don't get why this would be a problem; that's a 
> common development cycle and, unless 2.x takes years to be finished, it is 
> hardly an issue for players.

  I suppose it depends on how often we plan to do major releases.  If only every 
couple years, this can lead to other problems:
1) To players/users, the project may appear dead (nothing new in the past 12 months)
2) To developers, less satisfaction making changes if no one (outside perhaps a 
very limited set of developers) will see it for 12 months

  This can be solved by doing major releases every 6 months (or a year at max) - 
but that then limits number of changes that can be done in each for each major 
release.  Which may not be a bad thing, but just a note.

  But last point is scope of changes - if major changes break compatibility, you 
probably don't want to do them too often - players (and server admins) probably 
don't want to have to start from scratch every 6 months.


> So I'd suggest to branch whenever we make a new stable release, whatever its 
> version number. The "main" CVS should contain the latest, work-in-progress 
> stuff. The various branches (1.9, 1.10, 2.0) get only bugfixes and can be 
> used to create package revisions (1.9.1, 1.9.2, etc).

  That more or less matches what I said for the CVS branch.

  I guess if we're not really concerned about stability of major releases, doing 
pre-releases isn't necessary.  But given that major releases will have much 
larger scale changes, I'd see that number of severity of bugs to potentially be 
larger.

  Likewise, if the code isn't being used very much until it is released, it 
means that a bug for a big change may not be discovered until a year after that 
change is made.  I know from my own developing perspective, I'd much rather find 
bugs for code I do relatively shortly after I do the code, because the code will 
be fresher in my mind than if I have to look back at something I did 6 months ago.

  I suppose in short what I'm saying is it is really nice to have all code 
actually exercised/used somewhat shortly after the code is written.

> I think the confusion comes from that currently, a lot of people are using the 
> CVS directly and don't care about the file releases. I don't think it is the 
> best way to ensure a smooth transition process between version, and pertly 
> explains why some important projects get delayed or lack coordination 
> (because the current general assumption is that "the CVS must always work").

   yes - that probably isn't a good approach - I think under a new system, 
servers will need to keep to the stable branch.

  At the same time, the number of changes in the stable branch will probably be 
a lot less, so perhaps not as much an issue for servers to keep up to date on that.


> 
>>   Problem is that then we will never make another major release, as the
>> list of things to do will continue to grow.
>>
> No, because you can impose a time limit to submit new ideas that needs to be 
> incorporated to the 2.x line. Say for example that "we end discussion on 
> August 31th", have a debate during the first week of September about the 
> submitted ideas, who will do what and what can be dropped because of being 
> too ambitious/irrealistic/whatever else.
> Currently, there is no such team planning - it is basically "free for all"; it 
> has its advantages of course, but also major drawbacks, like the inhability 
> to planify what the next major release will contain.

  Fair enough.  But that model sounds more like 'everyone say what you plan to 
do  for the next major release by august 31st'.  Everyone discussing what to do 
is also good.  People saying what they will do is needed.  Yet at the same time, 
I think some rough date has to be put out on when those changes will be 
completed by.  If changes are not done by the date, they get pushed off to next 
major version (there is of course some wiggle room here, but it isn't uncommon 
for other various things to happen in ones life which limits the ability to do 
the work.  If a month before the release the person responsible for it says 'I 
haven't done much work, and I can't continue', do we really put off the release 
for someone else to take over, or just put it off?

  If you put it off, then the danger comes that someone takes it over, and other 
developers, having completed there stuff, don't have anything to do, so start 
the process for some other big changes.  I suppose it can just be a simple case 
of 'well, even though 2.0 isn't out yet, your change has to wait to 3.0'.  Dunno 
what is really the right answer for this.


> I was speaking about functional bugs ("Things don't work as expected"), not 
> RFEs/whishlist (those I don't really consider as bugs, as they don't describe 
> functional errors).

  but that can be a question that is also hard to answer.  Looking at the bug 
list on sourceforge, I would say that perhaps a third to a half of those could 
be put in the not real bugs (enhancement requests).  But other people could say 
that they are bugs that really should be fixed.  At some level, it becomes a 
matter of of opinion.


>>   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.
>>
> Agree - the problem is that at the end of the process, we should get a clear 
> document (probably in the Wiki itself) precisely describing the final model. 
> That's currently not the case for most of the proposals.

  True - but at least for significant projects, proposals are supposed to be 
sent to the mailing list.  They are not necessarily copied to the wiki.  I at 
least have tried for the most part to send out proposals of what I plan to do.

> 
>>   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.  
>>
> I wasn't suggesting that a "committee" decide what others should code. But I 
> think it is not too constraining to say: "let's discuss about what we want to 
> do about the X improvement, and get a clear consensus about it".

  I agree.


> What I said is just that for anything larger than bugfixes or minor 
> improvements, we need a document describing (1)the goal to achieve and (2)how 
> to do it; something that would define the work in a clear and unambiguous 
> way. I also suggested that for major changes, such a document should be the 
> result of a consensus, and not a one-man decision.
> 
> Regardless of the size of the developers base, I hardly see how something as 
> simple as that would suffocate the devs and "make things too complicated".

  Perhaps you could provide an example of such a document?  From your 
description, I have no real idea how detailed or not detailed you are expecting 
it to be.

  But as a person who often has sent out e-mail describing changes I'm planning 
on doing, it is often not uncommon to spend a lot more time describing that, 
responding to e-mails, followups, etc, than doing that actual work.  Maybe that 
is to be expected, but at some level, not something I want to spend a lot of 
time doing.

  The flip side, and perhaps not really related, is need for people that are 
sending out proposals to follow through and do the code, or at least let us know 
that it isn't happening.  But more than once, there have been discussions about 
some new feature I think would be cool, and I take part in those, and then never 
hear anything about it again.  Certainly, someone else could pick up those 
pieces and do that feature, but then you don't necessarily know current status.

  Maybe as part of this, there needs to be regular updates from the developers 
about progress, just so it is known if someone disappears and thus we need to 
find someone else to do it, or that project should be written off, etc.


>> 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.
>>
> I don't understand why we'd have a single stable branch for each major 
> version. I think we'd need to create a branch for every stable release made 
> on the basis of a major release. I think this is justified by the fact that 
> we're much more likely to get revisions of a given major release than a major 
> release.

  Are you then saying there should be a stable 2-0-0, stable 2-1-0, etc?

  The only reason I can see of doing that is if there are going to be micro 
releases as well as minor releases (2.1.1 released after 2.2.0).  Given that I'd 
expect mostly bugfixes in this stable branch, I don't see that this is a very 
likely scenario (any bug fixed in 2.1.1 should also be in the main stable branch 
- if there is need to get that fix out right away, why not do a 2.2.1 then?)

  If there were significant changes in the minor releases, such that running 
2.2.0 might be considered risky, which is why you want a 2.1.1 since it is in a 
better known state.  But since I'm not expecting lots of changes in this stable 
branch, that doesn't seem really likely.

> 
>>   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.
>>
> That's why I don't think branching on the sole basis of the "major release 
> number" is a flawed idea. I think that saying "the next schedule for a 
> release is next month, so let's branch the code now that it is more or less 
> working, only fix bugs, and continue to put the new stuff in head.

  But this starts making things even more work intensive - if I make a change to 
the main head branch for a bug fix, now there is the potential I have to update 
the main stable branch as well as the micro branch for a potential upcoming release?

  Before going on that approach, I'd wait and see how much activity the stable 
branch is really getting, and if in fact it is getting any signficant changes 
other than bug fixes or other minor things.


>>   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
>>
> That's why I think branching on releases of a single major is a better idea, 
> as they would be done on a shorter cycle (in the range of 3 to 6 months at 
> most).

  Is that then saying a major release every 6 months or so?


>>   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.
>>
> That's exactly why I suggested the creation of a branch at each revision 
> step - those would be a close match to the "snapshots" you are describing, 
> except that we ensure to fix its bugs for its life duration (that is, until a 
> new revision is released).

  But I personally don't want to have to main several different branches and 
have to do updates to them whenever I make a change.

> 
>>   I think then also some form of filtering or a separate metaserver is
>> needed so players do play on the appropriate server.
>>
> We already have the "version" field in the metaserver to identify the 
> server-side of the versioning problem. As for the client, I'd say that:
> - A client should always work with servers with version numbers lower or equal 
> than its own (ex: a 2.4 client would work with 2.0->2.4 servers, but not with 
> 2.5 ones);
> - A client has no guaranteed compatibility across major revisions (So a 2.x 
> client will likely not work on 1.x servers).

  Yes - that is a reasonable model.  But I think the client needs to hide/filter 
that.  If I'm running client 2.5, it shouldn't show me server version 1.9 when I 
can't play on it.  Or likewise, it should show me server version 2.7 when I may 
not be able to play on that also (but in that case, it should perhaps print 
message saying it isn't the latest client and go update)