[ENet-discuss] 1.3.1 release preparation?

[Lee Salzman]

This indicates more of a problem with Linux distro packaging, since ENet 
is not  just a library but also a binary protocol. As such, 1.2 and 1.3 
are not drop in replacements for each other in terms of client 
compatibility, and Linux distros should be taking note of this in their 
packaging. It is unlikely I will really change the protocol since 1.3, 
but 1.2 had enough problems that it warranted the changes I made rather 
than letting compatibility concerns hold those changes back (hence the 
version bump to 1.3 from 1.2). So just bite the bullet and switch over 
to 1.3 while you can and be done with it, and I think you should be 
mostly problem free for years to come.

On 02/09/2011 04:33 PM, Thorbjørn Lindeijer wrote:
> 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
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>