[crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/

[Mark Wedel]

Nicolas Weeger wrote:

> I think one major issue is how long it takes to make a release.
> For instance, I know there are some things to do for Windows server/client 
> (and I will write that down somewhere!), but I don't know how long it takes.

  I know this release is taking a bit more time, but that is also because I'm 
documenting it.

  the arch and map stuff is pretty easy - it is basically make a copy to the 
branch, tar it up, and upload it.

  Even the server and client is pretty easy _if_ everything works correctly. 
The directions are basically update the configure.in, run autoconf, do make dist.

  The issue is when things don't work right - someone adds a file but forgets to 
update the makefile.  Then you go through, fix that, repeat the steps, etc, and 
hopes it works.

  Also, for the client & server, I do some extra checking, like can I run the 
client, log into the server, and have it work?  Just a basic 'this isn't 
completely brain dead' type of thing.  that takes some extra time, but after 
being hit one time with something being delivered that was braindead, it seems 
like a good idea.

  The time may also depend on your upload speed.  Uploading 40 MB of map files 
takes a little bit of time on an ADSL connection.

  But in short summary, I'd say that normally it takes the good part of an 
evening to do a release (2-4 hours).

  If releases are done more often, I'd expect this to go down some - likelihood 
of release process getting broken is less when there have only been 20 changes 
and not 200, etc.

> 
> IMO, what we should do is:
> * automatize to the maximum the release process. This can include writing sh 
> scripts for Linux, scripts for Windows, and so on. [as a side note, I'm 
> thinking of doing a small C program for Windows to replace the Perl script 
> for maps, and make the build process more easy, ie change version numbers and 
> such. C because Perl isn't needed, apart for arch collecting which i can do 
> on my linux box)
> * time how much time a release takes
> * decide after we automate to the maximum :)

  See other post about automation.  Certainly more automation can be done, and 
that shaves some time off.  I suppose the main advantage of automation is it 
could be something that you do a 'make release 1.11', go to bed, and next 
morning, log on to find everything worked and the files are uploaded to sourceforge.

  At least for me, it may be a little while before I trust everything that much.

  And I'm sure it could be automated more - I think it basically came down to:
A) Do a write a script to automate it more, which will take X amount of time to 
write and make sure it works
B) Just do it by hand, where it takes Y more time than fully automated

  Where Y*NUM_RELEASES > X, but unclear what value NUM_RELEASES are.  it's also 
a matter of time concentration.  If Y is 10 minutes, not a big deal - just means 
I go to bed a few minutes later, and shaving 10 minutes off probably means I go 
to bed 10 minutes earlier.  if X is 90 minutes, that is enough time to actually 
do something relevant - look into fixing some bugs, writing new features, 
whatever else.


> 
> I would aim for something like a release every 2 months. It may appear short, 
> but if release process is automated well we don't take much time to release. 
> It would enable us to have many tests and such.

  More frequent releases do also have the advantage that there is likely less 
breakage.

> 
> Note that we should probably do trunk releases too, so people get to test it.

  The trunk releases get messy, because from what I recall, what we have right 
now in trunk may not be compatible with final release of 2.0 (in terms of maps, 
locations, etc).  So it gets sort of tricky to put this out there, but don't 
rely on it too heavily, because things could change in incompatible ways.  But 
that sort of discourages people from using it.

  Its sort of a different discussion, but the compatible breaking changes should 
probably be done as soon as possible, so that the rest of more tweaking, fixing 
bugs, etc.  But time doesn't always work that way.