[crossfire] Release schedule/notes

[Mark Wedel]

alex_sch at telus.net wrote:

>> Other thoughts:  I'd say there is nothing prevent some micro releases of some 
>> components between now and then, if a change warrants it.  For example, map
>> and archetype changes are quite quick to do and contain perhaps some of the
>> more noticable changes to the player, so doing a micro release of those
>> between now and then may make sense.  Likewise critical bug fixes in either 
>> the server of client would warrant a micro release (1.10.1).
> 
> To me, it seems more sane to reserve micro releases solely to bug fixes of
> particular note (affects gameplay significantly or affects security). Generic
> quick changes seem like they wouldn't be worth doing micro releases for really.

  I generally agree.  OTOH, if someone wants to do a release of some component 
to fix some aspects, I don't think there is a big reason to stop them

  OTOH, scheduling has to be done properly - it doesn't make sense to do a micro 
release 2 days before the next minor release.

> 
>> Main trunk releases:
>> The server is going under some major changes - I'm not sure it makes sense to
>> do releases until that is sorted out.  Just from my experience with the 1.10.0 
>> release, it would seem that someone could otherwise be spending a lot of time
>> getting it so the release aspect of it works, only to have a lot of that work
>> go away as files and other paths may change.
> 
> Agreed. Also note, in terms of finishing major changes first, though the current
> going code changes are among them, we should also think about gameplay changes,
> think about what frusturates players, and think about how to change the game
> mechanics to improve that. Those things are even more important IMHO to
> warrenting a 2.0 release and we should remember that code restructuring while
> important, is largely so the gameplay changes and features are easier to deal
> with. I suggest in terms of gameplay changes/improvements, before we look at
> things like adding a character creation menu, we should look at things like
> movement/attack speed which are easier to change the algorithm for but require
> greater testing and thought IMHO. (Ok, done drifting off from Mark's topic :))

  Ordering of what to work on is always tricky.  Especially given the volunteer 
nature.

  What I'd put near the top:
- things which hold dependencies (I can't do Y until X is finished, so X should 
be done sooner, not later
- Changes that result in incompatibilities (say different save file format), or 
game play changes that would be hard to fix with script, making it so that the 
only fair thing to do is start with all new characters (changing how exp is 
gained, enchanting objects, etc, could fall into this case, with the older 
characters have a perceived benefit that the new characters can't get)
- Game changes related to balance, as the process of changing those could take 
quite a while (this character too weak at low levels, but too powerful at high, etc)

  while changes to gameplay themselves should be done sooner, not later, it 
depends on the change.  In the example of speed/attack speed - in some sense, 
that could be done at any time (even to the 1.x release), the main issue being 
that it could be confusing/misleading to players because they attacked at speed 
X, and now attack at speed X/2 for example, making things more difficult.  This 
sort of falls into the incompatibilies realm, but to a lesser extent.  IT 
probably also falls into the game game changes related to balance - if player 
speed is changed, that changes the balance all around - you couldn't do it late 
in the process.

  And while some cosmetic changes may not make sense, in other cases, it may 
make sense rather than doing two versions of the code.

  For example, if we change the way characters are created (like you get so many 
stat points), and even extend it to things like choosing some skills, it doesn't 
make a lot of sense to do it once with draw infos, replies, message states in 
the server, and then later, write up the nice GUI for it - in a sense, it is 
less effort to just do that gui while those other changes are going on so that 
code isn't written that is then thrown away.