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

[Kevin R. Bulgrien]

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

FWIW, I agree that it usually is going to take a balance between manual and
assisted.  I tend toward scripting the basic rote work that doesn't take
imagination.  Going to far with the hard stuff doesn't pay back, and is often
to easy to break quickly.

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

Perhaps a technicality, but having a distinction would make it "easier" to
release something even if there was a big bug unfixed, or it might be top of
tree so that new development gets tested quicker... and also encourages
new development to not go too long in an unusable state.

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

Not my intent.  Say Joe wants to run a server... he picks stable because he
mostly wants to play with a bunch of friends and doesn't want a lot of risk
that stuff will be busted.  Jack though, likes to hack around, and play the
bleeding edge, but he's not up to doing SVN checkout and build, so he goes
for the "unstable".  It's all up to the downloader.  It's not a new concept as
a number of big projects run that way... TortoiseCVS... CVS... etc.  I'd not
say it is without some downsides if not managed well.

Say you go for a release every four months, then maybe there are three
"unstable" releases between where people don't try as hard to get all
the bugs out... they are in essence, release candidates on steroids in
that there is not requirement for new features to not be added.  The 
point is to get the stuff tested, not to presume it is error-free.  Maybe
the schedule helps people stop putting in features after the last
unstable before a new release...  or maybe not depending on how
formal you want things to run... but that might help people plan
what to work on so that bug fixing gets attention as well as adding
new stuff.

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

When I said release quality, I was meaning that I wouldn't necessarily want
someone to think I thought they were polished, but since they were in SVN,
someone could hack on them when  I didn't.  It seems too bad to hoard a
script just because I don't know where junk like that goes.  It seems harder
to add a file in a maps directory, etc if your just hacking around a proof of
concept that might just fizzle.  Having a tools area might make it easier to
chuck something in in case someone else might look at it and go... hey...
that's a cool idea, but how about doing it this way... or whatever.  I tend to
feel less confident about uploading a script into say maps, or server if I'm
not sure someone else would even use it, because it would be easy to be
seen as clutter especially if abused.   If a script matured and got heavily
used, it could be moved to a more permanent location that was in the
directory it was most applicable to.  The other thing is, that it is hard to
know where scripts are and what they are for right now.  If there was an
obvious top-level directory for that sort of thing, it would make it much
easier to find out what was available to try on for size.

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

Agree mostly...  but still think there might be an advantage to having them
collected in a common scripts directory that had subdirectories named
after the arch, maps, etc. they serve.  Don't know SVN well enough, but
it could be you could have some kind of "view" that also put them in
the directory where they were most likely to be used, but as far as
version control went, they were controlled in the common tools area.
Mostly this is just thinking out loud.  Don't know if it fits the project, but
since I write scripts that aren't in  SVN I was thinking about how I might
be more likely to put them up for people to look at and adapt for their
own use.