> Such a scripted packaging system has been tested on ailesse for the binary > client (Just like the current Gridarta/JXClient daily builds, it generated > Debian packages, then RPM ones through Alien). It had been removed last > year for basically two reasons:
> - Architecture portability issues: although the client could be > cross-compiled for other architectures than x86 (at least x86_64, ARM and > PPC were supported), there was no way to ensure the non-x86 packages > produced a working result. Since a package version always automatically > replaced the previous one, chances to screw up a non-x86 installation were > estimated too high to be acceptable; > > - Distribution portability issues: Packages could only be built reliably > for Linux. I wasn't able to implement cross-building for Solaris, FreeBSD > or OSX; Non-Linux builds are always hazards. AFAIK, releasing has little to do with breakage. The more serious breakage is due to incremental development and a failure to release in a timely manner. Frankly, I see this as a lesser issue than the failure to make current development available Further, automated releases were only one possibility mentioned. The other was for periodic release. From what has been said in the past, it seems releases are not done because it is difficult. The script makes it not difficult. > Given the time it would have taken to properly fix those issues - and I'm > actually not sure they could have been - and also given that another client > was already available as a daily package, daily packaging of the C clients > has been abandoned. Not everyone is satisfied with the current state of affairs, and one of these is trying to contribute something positive. > This experience showed that what was difficult was not the packaging > process itself, but ensuring that it gets supported outside the > Linux/x86(_64) world. If there is something new released, and if someone cares about non-x86, they can deal with and contribute to build and packaging. If no one cares, then... what good reason is there to care about such an ideological issue? Besides, people should be able care less whether some niche group happens to like a different x86 client while the rest of the world explores the cross-platform nirvana demonstrated by the other client. > > Are there any good reasons left to avoiding putting the > > 2.x client out there? We're going on two years of client enhancements > > with no releases. That can't be helping project exposure any. > > The fact that the 2.x server itself is still a highly moving target, and > thus that a release would be very prematurate. To me, it seems that a > release, unless marked specifically as "alpha/beta", needs to be relatively > stable and finished. Firstly, this ignores the fact that the "2.x" client is still branch compatible many months after 2.x was created, and it has many enhancements that should be available to branch players. When this is no longer the case this will seem more like an relevant comment. Secondly, the script builds RPMs and binaries that are marked with the SVN revision number. If this is not clear enough, it is trivial to add other static markings. In summary, though the arguments presented make it sound reasonable to dispense with the idea unattended builds, they do not seem to provide a reason to continue to leave a perfectly good client with improvements unreleased. The script is presented primarily because when I have lobbied for release previously, one of the reasons given was that it was so difficult to make a release. I aimed to remove the possibility of being given that reason again. At this point, to my knowledge, the branch clients have the same instabilities as what is on trunk, but offer fewer options to players. I did a lot of work on that client. I'd like to see it getting put out there for people to use. I think that's easy to understand, and do not see why it should be so quickly argued against. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
