[crossfire] 2.0 release, was Re: Code restructuring

[Yann Chachkoff]

Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit :
> Yann Chachkoff wrote:
>   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
>
Well, at least for the code side of things, it seems to me that a software 
that shows "serious problems" should not get released.

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'd also like to underline that other games suffered serious problems at 
times, but it wasn't hard to convince people to try the next step, provided 
that they initially found the game promising/fun/interesting enough. If we 
are not sure of this, then we may have a content problem that needs to be put 
on the table.

>   And if the changes break compatibility, that makes it even less likely
> for servers to switch over.
>
As long as an old version will only get bugfixes, servers will switch over 
anyway, to have access to the new cool and shiny features. But again, the 
interest of the new stuff should be strong enough and, if we believe it may 
not, then we have a problem regarding the content of the game and our 
relationship towards the player side of the community: it would basically 
mean that we work without understanding what players need/want/await for.

>   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) 
>
Sorry if I sound rude by saying this, but that's ridiculous. Since when a 
project that mostly releases revisions of a given version is 
considered 'dead' ? To take a simple example, PHP 4.0 was released in 2000, 
and PHP 5.0 'only' in 2004 - did people consider it a 'dead project' in the 
meantime ?
Again, I am not saying we should provide "nothing new" - but simply not 
include "major changes". And I think there are plenty of smaller-scale stuff 
to keep us busy to provide minor releases anyway.

> 2) To developers, less satisfaction making changes if no one 
> (outside perhaps a very limited set of developers) will see it for 12
> months
>
First, there are changes that can be introduced by each minor release. Second, 
major changes worth an upgrade of the major version number are likely to take 
a long time to complete, maybe months, so the "waiting time" is unlikely to 
be a problem - you cannot be upset that your code isn't used if you haven't 
even got enough time to finish it.

>   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.
>
Why would we ever need to base major releases on arbitrary dates ? That's a 
terrible idea, IMHO. Such changes should be based on the features first, and 
*then* on some kind of deadline to complete the work, not the reverse.

>   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.
>
Sure. I was more thinking about a rather long cycle for majors - one every two 
years or so, possibly even longer.

>   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.
>
Then simply open a public beta server using the last usable CVS code. There's 
no need to play with "pre-xxx" labels of any kind for that.

>   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.
>
Yes, indeed. But that would also include some testing made by the developer(s) 
it(them)selves. Often, changes made in the CVS currently result in an 
unusable code because of gross errors that could have been avoided if the 
coder had spent ten more minutes to build, install and test his/her new 
addition. 

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

>   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. 
>
Yes, but you cannot define the deadline for implementation before having a 
list of all changes to be done.

> 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?
>
It depends on the importance of the missing piece, and should be discussed on 
a case-by-case basis. It also depends on what's already done - if 50% of the 
work is complete, then it may worth delaying the release a little to complete 
it; if it is still at the design stage, then it may get dropped until the 
next major.

>   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.
>
Well, that's a teamwork/cooperation problem. I never suggested that each 
specific person should code one and only one part. If some developers have 
finished what they wanted to work on while others haven't, of course the free 
ones can jump and help on the remaining things. Having a clear definition of 
the tasks doesn't prevent one to have some flexibility.

> > 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.
>
At which level ? My definition is pretty clear: do the rules 'claim' that it 
should work like X, but in fact that works like Y ? Although there is of 
course a "gray zone", I think that it is pretty clear in most cases.
In the case a controversy arises about a specific point, then we still have a 
mailing list to sort it out and, if necessary, a project leader that can 
ultimately take the decision if no concensus arises.

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

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

>   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.
>
Yep - that's why I was suggesting that some document summarizing the project 
to be done on the basis of the discussion (probably as the discussion itself 
develops), so that somebody could quickly get all the infos needed on it 
without having to browse mailing list archives to pick up the pieces. It 
would also help gathering who is working on what, and thus monitor the 
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.
>
Yep. 

>   Are you then saying there should be a stable 2-0-0, stable 2-1-0, etc?
>
Yes. I'm saying that we should have such minor stable releases, just as we 
currently do with 1.x.

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

> 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?)
>
First, of course a bug should get both in the stable branch it was first 
discovered and in the CVS head; second, why not do a 2.2 instead of releasing 
a "fixed 2.1" ? Well, precisely because it is just a fix, and not a new 
revision with new stuff in it, game enhancements, new maps, etc.

>   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.
>
I don't see why you wouldn't see "lots of changes" - You wouldn't see lots in 
each minor release branch for sure (only bugfixes); but you'd do in the main 
trunk, which is where all 2.x-related development would take place.

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

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.

>   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.
>
Let's be clear: I'm not suggesting to create a "stable branch" opposed to 
an "unstable" one. I'm suggesting that the head is to be used as the basis of 
a regular branching to stable code (thus, if head contains 2.x code, it will 
produce 2.1, 2.2, etc stable branches).

> > 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?
>
No. As I said, major releases shouldn't happen often. On the other hand, minor 
releases should. 6 months seems way too short a cycle for majors IMHO.

>   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.
>
In my model, you'd only have to care about two: the head (of course), and the 
last stable branch for bugfixes. That's basically not asking more 
than "following" the last version released and support it - and I don't think 
supporting what we release during its life duration is too much asking (yes, 
I know, bug fixing is less fun than introducing new stuff - but that's part 
of the things that need to be done regardless if we like them or not).

>   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)
>
I think that at first, we could simply show a warning dialog when the version 
doesn't match the accepted range.