[ENet-discuss] 1.3.1 release preparation?

[Thorbjørn Lindeijer]

On Wed, Feb 9, 2011 at 03:09, Lee Salzman <lsalzman at gmail.com> wrote:
> So, I am probably going to roll out a 1.3.1 release soon. The main change in
> it would simply be the reliable packet throttling idea that I had thought of
> earlier, as well as some bug fixes discovered in the testing of it (which
> also merit a 1.2.4). Are there any other small things people would like that
> are applicable for a sub-point release? Please no pie-in-the-sky requests,
> this is just a 0.0.1 version increment. :)

Probably out of the scope of a minor release, but in our 2D MMORPG
project we're wondering if there are any plans to keep backwards
compatibility between minor ENet versions. At the moment we're having
trouble figuring out how we could realize an upgrade path, especially
taking into account Linux distributions.

So since ENet 1.A doesn't do anything useful when connecting with ENet
1.B, and neither the other way around, we've opted to include the ENet
sources in both our client and server software. However, that doesn't
enable us to upgrade the version of ENet used by the server without
simultaneously updating all the clients, and that's where the problem
starts.

The other side of the problem is that Linux distributions like Fedora
and Debian are not happy to compile 3rd party libraries along with
projects. They'd rather depend on a single copy of the library
available on the system in order to reduce maintenance overhead.
However, that means that when a distribution would choose to upgrade
its version of ENet, suddenly our client can no longer connect to the
server.

If keeping compatibility between ENet versions is somehow not possible
or not within your scope then we'd have to either pick one version of
ENet and stick with it (and make Linux distributions unhappy and
maintain this version of ENet on ourselves) or have some kind of
fallback solution that clients using older or newer versions of ENet
can use to still connect to the server. Or maybe we should just go
back to TCP or look for alternatives that offer better compatibility
(though I'm not aware of any).

I'm curious about your point of view on this.

Best regards,
Bjørn