Re: Library Versioning

["Andre Carregal" <carregal@...>]

> De: Diego Nehab <diego@tecgraf.puc-rio.br>

> > luasocket-2.0-lua5.1.tar.gz
> > luasocket-2.0-lua5.2.tar.gz
> > luasocket-2.0-lua5.3.tar.gz
> 
> This is a very good idea. I am going to start doing this. Unless someone else has a better idea.

I'm not sure if this applies to source versioning, but surely applies for binary versioning.

Source versioning relates to a published API, so if a module does not change its API for Lua 5.1 but compiles for it, ideally the module source should remain at the same major.minor version (the third number would change if the source has modifications but not the API). Note that this is valid for both C and Lua modules.

On the example above, the tar.gz files appear to be source only, so as long as LuaSocket 2.0 offers the same API for the three versions of Lua mentioned, the source distribution should remain a single file (luasocket-2.0.tar.gz), while the binary distribution could be spread in as many combinations as there were platforms and Lua versions (see LuaFileSystem 1.2 on http://luaforge.net/frs/?group_id=66&release_id=405 for an example).

By the way, since versioning is being mentioned, what about adopting some versioning policy for Lua modules? That would make things easier for module users and could open the doors for a Lua package manager such as Rocks, that have to take in account the module upward compatibility.

As an example, a policy like http://docs.rubygems.org/read/chapter/7 is being used for Kepler modules.

Andre