[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

Yann Chachkoff wrote:
> Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit :

> Now, you could say that "there is no way to be sure that the server works 
> before trying it"; I'd answer to this that (1) we developers are supposed to 
> do at least some rough beta testing and (2) nothing prevents us to set a 
> single beta-testing server clearly flagged as such to get player's feedback 
> and spot what could have been missed during development.

  I don't think any developers writes code with known bugs (at least I hope not).

  while some bugs are pretty obvious if good testing was done, some are less 
obvious (occur on specific map due to specific setting of flags on objects, 
etc), but can still be very severe.

  So I think it is fairly likely that with major changes being made, there will 
be some number of bugs.  A beta server fixes this, presuming you can get enough 
players on the beta to test it.  That's a big unknown at this point.



>>   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.
>>
> Not really - there could be several minor releases, each made with a 
> relatively short lifecycle (in the order of two-three months, maybe) that 
> could potentially include a lot of new stuff; the point is that during each 
> major, no huge, breaking change could occur, so the evolution would be rather 
> smooth for the server maintainers. They'd also benefit from having releases 
> that would be more solid than they're now - we currently make no bugfixes 
> outisde of the CVS itself, forcing them to use the potentially unstable CVS 
> content to get the fixes.

  Right - I don't think anyone right now is arguably against having the head be 
bleeding edge and aimed for the next major release and another (or multiple) 
stable branches.

  The question is what goes into the stable branch.  By its nature, everything 
has to go into the head branch (presuming the change is still applicable).  But 
the scope of changes for the minor releases in the stable branch probably 
shouldn't be too big.


> Well, that's part of teamworking. Coding is just the last part of the 
> process - the design phase, which includes the various discussions, seems at 
> least as important to me, if not more.

  There have certainly been cases where things were put in without any such 
discussion, and I would have liked to have seen some.

  And the question also becomes what level of changes require design documents? 
  Just the major feature?  Any feature beyond some scope (which would need to be 
defined?)  The danger can become that code is submitted/committed that should 
perhaps have a design document but there wasn't one.  Suppose a patch is 
submitted without a design document?  Do we just say 'no design document, do 
commit?'  That may be the right thing to say, but also probably isn't going to 
make developers very happy.

  I do think design discussions should be done.  But in doing so, I think some 
rules need to be formulated for when a document is or is not needed (and we have 
to be careful about code submissions - we don't necessarily want to reject them 
out of hand, but at the same time, we don't want to accept code that doesn't 
meet standards).

  I think also it may be best if all the major features go through design 
discussions even if there isn't anyone that is necessarily going to work on them.

  I know that for me personally, there are times when I am unexpectedly ready to 
do some coding.  However, if it is going to take 2 weeks to get input from a 
design document I write tonight, then 2 weeks from I may not have the time or 
inclination.  So there needs to be something that people can just pick up when 
ready.

  I usually try to get around this by putting things out for discussion even 
when I know I don't have time right now to work on them, on the basis that when 
I do have time, all discussion is done.  Problem then is it can be a very long 
time before I ever get to it, and if enough time passes, original discussion may 
not be relevant.



>>   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).  
>>
> There would be. Suppose that we release a 'stable' 2.1.0 version, put into its 
> own CVS branch. Now, somebody finds a couple bugs that we correct. We'd then 
> update the released package, numbering it 2.1.1, so that people understand 
> this is a fix of 2.1 rather than a version with new features.
> Note that CVS-wise, I do not suggest sub-branching 2.1 into 2.1.0, 2.1.1, etc; 
> that's unnecessary overkill.

  But then how do you cover the case like this:
2.1.0 released.
someone puts back some signficant change to stable branch.
critical bug is discovered, fix is made, but a 2.1.1 release is needed a week 
after 2.1.0

  One can release 2.1.1 from the stable branch (just like I do now), but that 
would also include the significant change, which then confuses the numbering 
scheme (suppose that change is signficant enough that it would be enough by 
itself to bump the number up to 2.2.0)

  Do we just release 2.2.0?  I suppose that is fine, but then maybe gets 
confusing if you release 2.2.0 a week after 2.1.0?



> As I said, I am not suggesting to do such micro-branches. Why would you need 
> to ? Just put the bugfix both in the head and in the last minor revision 
> branch (2.1, 2.2, etc). Then repackage the latest minor branch CVS and mark 
> it with an increased revision number (I suppose that practically, we'd not 
> want to repackage each time a bug is fixed - this could be done each time a 
> critical bug has been fixed, or on a weekly basis, provided that stuff got 
> fixed during the week).
> So in my proposal, you only have to fix things at two places: the last minor 
> revision branch, and the head.

  So it sounds like you have a branch for each minor release then?  Where do 
those branches come from?

  I think that all the 2.x minor releases have to start from the same main head 
- 2.0.0.

  But I'm not sure that makes things easier - it seems then you get this situation:

2.0 release.
branch for 2.1 is made based on 2.0
2.1 is released, branch for 2.2 made based on 2.0
This new branch now needs to be synchronized up for all the 2.1 changes.  And 
changes for 2.1.1 will also need to be synced up.

  And so on for 2.3, 2.4, etc.

  That seems to make it more complicated than having a stable-2-x branch and 
then  if necessary making a new branch for micro releases.

  I think also with what you suggest, the version numbering of files could get 
really confusing (and/or because of the merging, being able to do diffs and see 
what was specifically changed in a release becomes more difficult.

  I really don't want to have to have 3-4 different CVS trees around to be able 
to figure out exactly when something changed and what the code looked like 
before then.

  Maybe that isn't what you are suggesting, but from reading your e-mail, that 
seems to suggest how you are suggesting to do revisions.

> I can see two likely cases that can happen:
> - Either a player finds a bug; then, the bug is first spotted in the last 
> minor branch, and that's where the developer will fix it. Then, it will get 
> fixed in the head, provided that it is still relevant;
> - Either the dev working on the head spots a bug there. Then, it is his/her 
> responsability to immediately check if the bug exists in the latest stable 
> release as well; then, fix in both.

  Yes - I agree that is the correct process.


> Note that in most cases, it shouldn't be a big overload of work, as the latest 
> stable branch wouldn't be very far away from the head content.

  I don't see that being the case - if the head branch has been worked on for 1 
year with numberous code re-orgs, I'd expect the stable branch (for say 2.5) to 
look quite different.

  Unless you are suggesting that minor releases are branched from the current 
head code, eg:

2.0 release.
branch for 2.1 is made based on 2.0
2.1 is released, branch for 2.2 made based on current head code
2.2 is released, branch for 2.3 made based on current head code

  If that is the model, then that really isn't any different than what we do 
right now, which means by the time 3.0 is really released, it won't look that 
much different than the last previous minor release, since the code for that 
previous minor released was based on code pretty close to the 3.0 release code.

  I guess I'm just confused on what you are suggesting for how the minor 
releases are made/branched from.