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

[Mark Wedel]

Kevin R. Bulgrien wrote:

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

  Ok.  I think bi-annual may be too infrequent, by every 3-4 months is probably 
reasonable.

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

  I'm documenting the process as I go along.  What I have so far is at:
http://wiki.metalforge.net/doku.php/crossfire_release_guide

  (I have yet to the server release)

  Some things could perhaps be scripted more than they are done now.  For 
example, I could certainly see a top level script along the lines of 'make 1.11 
release', which goes, does the svn copy (to the right name), and perhaps even 
collects that archetype, maps, and sounds.

  Some of it gets trickier - for example, to make the ChangeLog file appear a 
little nicer, I remove the 'for top of SVN' in the branch - and just have 'Fixed 
in release 1.10'.  That could perhaps get scripted, but becomes a question of 
whether it is worth the time to try and script it (it may be that the automatic 
script fires up an editor).

  OTOH, automating it too far may be bad.  IT may very well be a case that we 
say we'll do a release on some date, and someone says they'll take care of the 
archs, another says they'll do the maps, etc.

  Aside from splitting the load, there could be other reasons - the person doing 
the most work with the arches may be the person that is also doing the release - 
this makes sense - he'll know when his changes are in, etc.

  there are also some things just not easily scriptable.  Like for me to build 
the 32 bit rpms, I have to boot my other computer, log in, run the commands, 
etc.  Running the commands to build the RPM is the easy part - it is the other 
steps that take more time.

  In terms of more frequent 'build' releases, I'm not sure how that really 
differs from a normal release.

  If it is a semi private release (not uploaded to sourceforge), it probably 
won't get as widespread testing, and in fact may not get any testing.

  If it does get uploaded to sourceforge, then it basically becomes like a 
normal release - people are going to download that (so better make sure all the 
bugs are fixed in it), etc.  I also think there is some limit on how often you 
can release those and get real feedback.

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

  That makes some sense.  But from the description, it seems a little odd.

  If the scripts are not of release quality, there is nothing preventing us 
right now from putting those in something like maps/scripts-nrq (non release 
quality), and then just not include that directory when the data is tarred up.

  That may make more sense than putting them in a top level script directory - I 
just have visions of hundreds of scripts there, with no real clue what half of 
them do, and then you start wondering if this or that script should be deleted, etc.

  I think it also makes sense to have script dirs in the arch and map 
distribution - there are already a bunch of map checking scripts in the server 
area, but that doesn't make a lot of sense - people don't necessarily know that 
they are there, etc.