Module versioning differs for libraries and applications: libraries need a libtool version specified in addition to their package version. Applications just have a package version.
Libraries and applications have a package version of the form major.minor.micro. ()
Libraries additionally have a libtool version of the form current:revision:age. ()
Version numbers should be updated for each release (using release and post-release increments). ()
Package versions should be incremented for feature changes or additions. ()
Libtool versions should be updated for API changes or additions. ()
Even/odd minor package versions can be used respectively for stable/unstable releases. ()
Both libraries and applications have a package version of the form major.minor.micro.
The package version number is that passed to
AC_INIT(), and the one which is typically known as the
project’s version number. For example, the Debian package for a library
will use the library’s package version (though may also include the major
version number in the package name to allow for
parallel installability).
Package versions are updated by the following rules:
If breaking API compatibility in a library, or making a large change to an application which affects everything (such as a UI redesign), increment major and set minor and micro to 0.
Otherwise, if changing or adding a feature, or adding any API, increment minor and set micro to 0.
En caso contrario (si se hace una publicación que contenga sólo correcciones de errores y actualizaciones de traducciones), se incrementa la microversión.
Tenga en cuenta que el número de versión menor debería actualizarse si se añade alguna API.
Las bibliotecas tienen dos números de versión: una versión libtool que rastrea la compatibilidad ABI posterior (). y una versión de paquete que rastrea los cambios de las características. Estos normalmente se incrementan sincronizadamente, pero deberían mantenerse separados porque la compatibilidad ABI posterior no está necesariamente relacionada con los cambios de las características o las correcciones de errores. Además, los dos números de versión tienen distintos significados, y no puede generarse automáticamente el uno desde el otro.
Un buen resumen del versionado libtool, y las diferencias con el versionado del paquete, se da en el cazador de mitos de Autotools; otro está en el manual de libtool.
Para actualizar la versión libtool, siga el algoritmo dado en los comentarios debajo. Este es un fragmento de código
# Before making a release, the LT_VERSION string should be modified. The
# string is of the form c:r:a. Follow these instructions sequentially:
# 1. If the library source code has changed at all since the last update, then
# increment revision (‘c:r:a’ becomes ‘c:r+1:a’).
# 2. If any interfaces have been added, removed, or changed since the last
# update, increment current, and set revision to 0.
# 3. If any interfaces have been added since the last public release, then
# increment age.
# 4. If any interfaces have been removed or changed since the last public
# release, then set age to 0.
AC_SUBST([LT_VERSION],[0:0:0])
El siguiente fragmento de código se puede usar en un
my_library_la_LDFLAGS = -version-info $(LT_VERSION)
La mayoría de los módulos de GNOME siguen una convención para publicaciones estables e inestables. La versión menor es par para liberaciones estables y es impar para las inestables. Por ejemplo, las versiones 3.20.* son estables, pero las versiones 3.19.* son inestables. Las versiones 3.19.* se pueden ver como entregas alfa y beta de la versión 3.20.
Una nueva microversión estable (por ejemplo 3.20.0 → 3.20.1) no añade nuevas características, sólo actualizaciones de traducciones y corrección de errores. Por otro lado, las micropublicaciones inestables (por ejemplo 3.19.1 → 3.19.2) pueden añadir API, o cambiar o eliminar la API que se añadió en la micropublicación anterior en esa serie menor.
La versión libtool debería actualizarse sólo para versiones de paquete estables.
El proceso estándar para hacer una publicación de un módulo incrementa la versión libtool (si el módulo es una biblioteca) en el momento de la entrega, por lo que incrementa el número de versión del paquete inmediatamente después (a esto se le llama un incremento posterior a la publicación).
La actualización de las versiones libtool durante el tiempo de publicación significa que sólo se incrementan una vez para todos los cambios ABI de una entrega. Usar el incremento posterior a la publicación para las versiones del paquete significa que el número de versión del paquete no está desactualizado (aún igual al de la entrega anterior) durante el ciclo de desarrollo.
El proceso de la publicación (basado en el proceso de publicación de GNOME):
Asegúrese de que el código está actualizado:
Asegúrese de que no tiene cambios locales:
Si la publicación es para una versión estable del paquete, incremente el número de versión libtool en
Añada una entrada al archivo
Ejecute
Corrija los errores que surjan, confirme esos cambios, y reincide en el paso 3
Si
Ejecute
Si eso no funciona debido a que otros commits se han subido mientras tanto, ejecute
Etiquete la publicación:
Ejecute
Ahora la publicación está completa, y se puede hacer el incremento de versión posterior a la misma:
Incremente el número de la versión del paquete en
Ejecute
Ejecute
El archivo de paquete generado por