[Gnucap-devel] library version

[Felix Salfelder]

On Mon, Feb 08, 2016 at 01:29:01PM -0500, al davis wrote:
> should we be doing this on gnucap-devel?

sure, why not.

> On Sun, 7 Feb 2016 22:14:20 +0100
> Felix Salfelder <address@hidden> wrote:
> > [..]
> > (thinking about the gnucap package for debian...)
> > 
> > first of all, we should define a library version. libtool versioning
> > appears to be simple enough. we could start right now from version 0.0.0
> > ("current"."revision"."age"), for the forthcoming snapshot. in order to
> > be useful, these numbers must be adjusted for each snapshot or release
> > (not difficult [1]). 
> 
> It may make sense to follow the numbers I used with RCS.  The last
> version under RCS was 26, so if we start current there with 20091207,
> incrementing once per tag, the next one released would be 31, I think.
> I need to check on what header changes happened in that time.  Not all
> had significant header changes.

in RCS there has never been a library... from [1]

"""
Never try to set the interface numbers so that they correspond to the
release number of your package. This is an abuse that only fosters
misunderstanding of the purpose of library versions.
""".

my understanding is, that *if* we swich to libtool versioning system,
then we should only apply it to the library.

> I have been thinking of restoring those numbers anyway.

i wasn't quite sure where these numbers have gone. i agree that they
should be continued. then, tag_number+26, snapshot version and
tarball/release/package version are just the same thing. (good.)

> A difference in use ... the "revision" was incremented with every
> commit.

so actually, the "revision" did just count the commits. this is not
easily possible with git. anyway, "revision" in the libtool sense
should follow the tags, not the commits. the number of commits is
irrelevant for the library version. still i would like to see it in
patchlev.h, but that is another story (see below)...

to the point. we have "version" and "commit", none of which should be
part of a library version. libtool versioning is (imo) the way to go.
this will introduce three more numbers. "cur", "rev", "age".

five numbers is a lot. but all of them are expressing mutually different
things. if we go with libtool versions, we should keep all of them.
more precisely

- version = tag number + offset (26?). this is also the tarball version
- commit = distance to last tag. 0, if there is no .git. (not implemented)
- libtool triplet = starting at 0:x:0, updated according to [1], i.e. at
                    most once per version.

to me, x=0 makes most sense, still. it is not meant to be a substitute
for "version".

> > I think lib/Make1 is a place prominent
> > enough to carry the version triplet, even though it is not currently
> > used by the build system. any other place is fine with me. what do you
> > think?
>
> include/patchlev.h  (long time tradition)

fine. then how about these

#define PACKAGE_VERSION 31
#define LIBGNUCAP_CURRENT 0
#define LIBGNUCAP_REVISION 0 // or anything really close...
#define LIBGNUCAP_CURRENT 0

?

cheers
felix

PS,OT,FTR: we should determine package_commit as in
  if "there is a git repo"
    lasttag=$(git describe --abbrev=0 --tags)
    package_commit=$(git log $lasttag..HEAD --oneline | wc -l)
  else
    package_commit=0
  fi,
then inject as PACKAGE_COMMIT, for the banner to display.
i simply don't know how to do that reliably :/


[1] 
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html