[crossfire] (Automated) Client Snapshot Releases

[Kevin R. Bulgrien]

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