[crossfire] 2.0 release, was Re: Code restructuring

[Yann Chachkoff]

(I fear I'll be overly long again, so fasten your seatbelts :))

Le jeudi 20 juillet 2006 07:29, Mark Wedel a écrit :

> > 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.
>
Sure - yet there are some commonly admitted "values" behind version numbers. 
Basically, an increase in the major number means a noticeable, significant 
break from the previous series; a minor usually indicates a "natural" 
evolution of a given codebase.

>   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.
>
That's a rather strange way of seeing things. The last iteration of the 1.x 
codebase is 1.9.1, not 1.0. There is no reason to evaluate a new release with 
one that was made several years ago, and long outdated by an extended 
evolution process.
To put it in another way, do you think players will compare 2.0 against the 
last known stable version (currently 1.9) or with the 1.0 that's five years 
old ?

>   Maybe that isn't great, but as I think was discussed elsewhere, 
>
I wasn't aware of this. 

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

>   So this means  
>   that a lot of those features have to put in to the previous version. 
>
No, I don't think so. You can backport *some* features if the new version 
takes too long to develop, but why would you want to do the work twice ? I 
see little interest in this.
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.

>   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 don't get why you would need to play with "pre-x" labels - that only adds 
useless complexity. Let's not forget that the CVS is essentially a 
developer's tool. Its content is by definition "unreleased code".
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).
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").

>   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? 
>
No, I don't think they need to. But if the goal of such snapshots is to 
provide some food to the beta-testers, then that's simple: whenever an 
important development step is done, create an archive of the CVS content, 
name it with a -bXX suffix and continue to code afterwards. I don't get where 
this would be a problem.

> Sort of goes back to whatever arbitrary numbering scheme we choose.
>
Yes, but the scheme would be a logical one, and not one that would be based on 
a rather vague "I think it is time to change the number" feeling.

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

>   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.
>
Yes, but I don't get the relationship between that problem and the current 
discussion.

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

> And 
> there may be many other bugs that fall more into the inconvenience of
> slightly annoying. 
>
Again, evaluate the bug against the "Does that work as expected ?" question. 
If the answer is "no", then that's indeed something that needs to be 
corrected as a revision of the current version. If that's a "yes", then it 
will get into the next (minor or major) release.

> 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.
>
Sure - but expecting that most bugs - the most visible ones, the most annoying 
ones - to be corrected is a very realistic goal.

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

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

> As in a volunteer project, I think we'd see a lot of specs and not a lot of 
> code. 
>
Volunteer doesn't necessarily imply that we should have no group 
organization - let's not confuse "volunteer" and "individualism". Currently, 
what we see is a lot of code, but not a lot of specs. I'm not convinced it is 
a better scheme, because it basically makes cooperation on a large scale very 
difficult; it also makes retaking an older piece of code more difficult, 
because you have to guess the initial intend of the original coder.

>   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.
>
Well, although I agree with the principle, I think you are completely 
misrepresenting what I described. I wasn't suggesting the complex creation of 
many internal hierarchical structures that would work like a men-in-black 
administration !

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

>   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.
>
Agree. The head should be the main point of introduction of new code.

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

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

In such a scheme, there is no need for specific responsability over the stable 
branches - when a bug is submitted, first correct it in the stable branch, 
and then port it in the head, unless it has already been eliminated there.

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

>   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.
>
It doesn't seem to be a problem, provided that the release cycle is short 
(which I expect it wouldn't basing it on the major version changes rather 
than the revisions in a given version).

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

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