Quick notes (I've probably missed some - if I've missed anything important, follow up).
The list of supported platform is largely based on user input. I've not had a mac, so that is based on someone providing patches (if necessary) and saying it works. On going testing of those platforms does not happen by me, and maybe not at all. At one point, I think the list was a lot longer, but then we started asking 'just when is the last time someone tried to compile on irix?'. For what its worth, I've moved for redhat linux to solaris (x86/amd64) so cover that base. The official release cycle is slow for a variety of reasons - off the top of my head: - Broken release system - the tools/components are there, but changes have been made (addition/removal of file being most common) such that release/packaging fails. Not hard to fix, but takes time. - For official releases, desire to have stable components (no big check in the day before). But folks also like to have a chance to fix bug and make other changes before the release, which sort of goes against stability (fixing bugs should make things more stable, but not always the case) - Scheduling becomes a problem - between the packaging, uploading, and updating the page on sourceforge, it would be a couple hour process. It may be the case that I have the time right now, but to let everyone have a chance to put in the patches, change, etc it means a couple weeks time, when I may not have time. - The only real part of the official release was the source tar balls. Binaries may come later or not at all (I only did x86_64 rpms - never did anything more) On those notes, things to make releases happen more often: - Folks other than me doing releases. - Use standard release train model (release happens at this time - if change isn't done, need to wait for next train/release). - More frequent releases such that missing a train isn't as big an issue. - Do more frequent in between snapshots - if this uses same logic/scripts as official releases, it means that problems related to missing files get found sooner. A lot of that is easier said than done. I've also said that I'll try to do releases more often, but finding time to do so is often hard. And even on second point of release train model, I suspect that dates would be vague or in a range (something along the lines of 'Release schedule will be January, May and September'). That gives entire month to find the necessary time for a release, and not a specific day. One last note - with various free VM solutions out there, it now does make it easier to releases for multiple OS's or doing 32 bit releases on 64 bit linux (I know of the problem Lauwenmark speaks related to trying to do a 32 bit release on 64 bit linux - solution would be to have a 32 version installed in a VM) Now in terms of the 2.x branch: For the client, given that lots of good stuff has gone into the 2.x branch and nothing really removed that breaks compatibility, I'd be tempted to take what is currently 2.x and make it the main trunk (I'd need to think about it more and see what changes have been done). To prevent confusion, a long time back it was decided that the client would mirror server version - that normally worked pretty good when we were just doing incremental 1.x release, but doesn't work as good for 2.x. The reason for tying the versions together is it made support easier - just tell users to make sure their client was at least same version as server and things would work. But also since that time, the protocol has stabilized a great deal. Now the idea of the 2.x client (and thus server) was that at time of release of 2.0, the client would fully support the 2.0 protocol and nothing more (all code related to deprecated commands would be removed. All setup or other option related to protocol control would also be removed, such that at startup, the two would already be speaking the same language. Some setup commands related more to control/preferences would still be in place). Such a client almost certainly would not run on a 1.x server, and a 1.x client would not work with a 2.x server. But that hasn't happened yet, and the current trunk client certainly does work on the 1.x servers, so maybe it does make sense to take what is in trunk and call it 1.x - it would get more folks using the features that are there. It may just make sense to just work on trunk until such time when it really does become incompatible with 1.x clients. For the server, this is a trickier question - the trunk server clearly is not ready for official release - sure it will run, but work on balance and other areas need to be done. One has to ask what do we get by releasing it more widely - I think we'd certainly get a fair number of bugs or questions related to known issues. I'd be more tempted to do snapshot releases after certain major things are done but before the next one is started. And those release would still have to be marked as alpha/experimental. But maybe it doesn't even make sense then - if folks really want to play with it, having them know how to compile and get it from SVN may be a first level sanity check. The number of folks that download the server as is isn't that huge, and for pre-release test versions, I think it'd be even lower. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
