[crossfire] Release schedule/notes

[mwedel at sonic.net]

>>   I really thing, relative to the trunk, this is a brief outline of
>> steps:
>> 1) Finish with the major overhaul of whatever we plan to overhaul in the
>> trunk server for 2.0
>> 2) Set up some test server(s), see how they work.
>> 3) start worrying about making pre 2.0 releases once we have a pretty
>> good
>> idea that what we have will have some semblance to what final 2.0 will
>> look
>> like.
>
> Concerning point 2), we should have such servers starting from now. There
> are
> many things in trunk that aren't in branch, so it'd be a waste to wait too
> much before trunk becomes the officiel version :)

 Maybe.  To do so would require the following:
a) It should be difficult to impossible for 1.x clients to connect to a
server.
b) Perhaps they should not even be visible on the metaserver, or a new
metaserver architecture is needed.

 I say this because I think that the _worst_ thing that can happen for
crossfire is for unaware users to play on a 2.0 server.  They'd probably
say things like it is buggy as hell, unreliable, and be PO'd when at some
point the server is wiped because of imcompatible changes

  If the only way for someone to play is to download the SVN client and
compile it themselves, then at that point, I say they probably know the
risks.  This gets a bit messed up as related to windows clients, as
presumably ones would need to be made available, and people unaware
would say 'hey - 2.0 looks the latest, I'll download that'.

 The main thing here is that one bad experience probably carries the
weight of 10 good ones.

>
> IMO, doing a 1.11 release isn't necessary. We should concentrate on trunk
> (yes, there are many bugs, which is why we need to focus on fixing that),
> and
> only do bug fix releases of 1.x branch.

 If that is the case, that is fine.  But if that is the case, then a lot
of stuff that is getting backported to the 1.x branch probably shouldn't
get backported.

 The problem is how do you define a bug?   Or maybe the question here is
severity of bugs.  Because if only 'bugs' are backported, there are going
to be enough changes to warrant more 1.x releases, and portentially
enough changes in those to call them 1.11, 1.12, etc.

 Also, backporting some 'features' to 1.x could be a good way to get
testing on them.  Polymorph might be such an example, and there may be
others.

 But from lots of previous discussions, it was decided that 1.x would
remain the stable branch, with regular releases, with the trunk branch
not making releases for quite a while.

 We could of course change this policy, but this was something
decided/discussed not too long ago.  At some point, if we revisit every
decision 6 months after it is made, it sort of calls into question what
is the point of having these discussions and making decisions if we just
decide something new a few months from now.

>
> Nicolas
> --
> http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code,
> bref
> de l'aléatoire !]
>
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>