[crossfire] Release schedule: was maps/tags/1.10/

[Kevin R. Bulgrien]

> Looking back, the only thing I might really change is perhaps saying something 
> on irc like "I'm going to do a release starting right now - if you have anything 
> ready to commit, let me know now and commit it", to catch any of those ready to 
> commit fixes (but that in itself can sometimes be dangerous).  If I had a time 
> machine, I'd send a note to myself 2 weeks ago to send mail to the list saying 
> I'm going to do a release in 2 weeks.  But I have to go on what I knew at the 
> time, not what I knew later.

Ok... and not to beat a dead horse, but my fixes were in easy maps, the ones most
likely for new players to see, which is why it gave me heartburn, and this kind of
heartburn is what you begin to address below, so we are on the same page.  I
know some distributions will ship 1.10 with those glaring bugs, and a slow
release means I just let them out the gate for who knows how long even if
I didn't have a hand in when the release occurred

>   Otherwise, I still think my decision to do a release now is better than 
> waiting another 2 months for a release.  Even though the code has some bugs, I'd 
> say it is better than what is out there right now as 1.9.1, and at some level, 
> getting code out there for others to use has some advantages.

I'm not totally on the same page here.  I think I would be if there were stable and
unstable releases, and if we were talking about an unstable one, but... on the
flip side, I get the point that it should not have waited another 2 months... and
agree on that point even though there rarely seems to be a truly acceptable
reason for releasing without mentioning it to co-developers.

>   This is one of the arguments for frequent releases - sure, each build will 
> have some bugs, and could be made better if delayed, but by getting the builds 
> out there, you get people to discover some of those new bugs so that they can 
> get fixed in the next release.  If infrequent releases are done, quality may in 
> fact not be better because people are stuck using an old buggy build for a 
> longer time period.
> 
>   Now to turn this more constructive, I think the real question is:  How often 
> should we be doing releases?  Every month?  Every 3 months?  Somewhere in between?
>
>   I think anything more frequent then every month (save for critical builds/to 
> fix something DOA) doesn't make much sense, as I don't think the 1.x branch is 
> changing fast enough.
> 
>   I also think that less than every 3 months is too long a gap - just looking at 
> the client, there were lots of things changed since the last release, such that 
> if there were 3 releases in that time period, each would still have enough 
> changes to be compelling.

More frequent releases than quarterly for stable releases seems questionable,
and would propose a tri-annual or bi-annual stable release to better line up with
major distribution release schedules.

As far as getting more testers running the code that doing monthly or bi-monthly
build releases is a good idea (all the way to packaging so that the release process
itself can be tested).  I only see this possible if the release process is documented
and scripted as much as possible.  At work, I do releases where I use a document
and a special make file that does all the tasks between events that need operator
intervention... using the Makefile as a simple library of things that need to be done...
a la `make zip`.

On that note, I'd like to see a top-level "tools" directory added to SVN to encourage
us to put our utility scripts in SVN for others to use.  I worked a bit on a map spell
checker, for instance, but because it is not good enough to "release", it rots in my
working directory.  Such a directory would be a great place for scripts that could be
used to manage SVN's bizarre concept of making you either waste disk space or
have bazillions of individual checkouts.  It would also be wonderful for the release
process to be supported by scripts in that directory.

2 cents... maybe not worth much in some economies...

Kevin