#8 versioning per extension package (release and snapshot)

[Jannick]

Currently it is a bit difficult to put a proper versioning per extension package in place when working with either the git repo or a snapshot release. So, here an idea as to how to associate a (potentially dirty) version to each extension package:

• add an extension-specific (lightweight) git tag to the latest extension release with tag name, e.g., gawk-<extension>-<release-version> (like gawk-csv-1.0.5).
• with this extver=$(git describe --tag --match=gawk-<extension>-*) provides you with the (potentially dirty) version of the extension gawk-<extension>.
• for a snapshot release plug extver into configure.ac and run autoreconf.

The tag names and extension version strings in snapshots should follow a strict pattern for further processing.

I hope that I am not missing something such that this is provided somehow already.

Thanks.

[Andrew J. Schorr]

Hi Jannick,

Thanks for the suggestion, but please help me to understand better the problem you're trying to solve. Currently, when there's a new release of a package, the procedure is to update the version number in configure.ac in the AC_INIT and make an entry in the NEWS file. If I understand correctly, I think you're asking us to add a git tag as well labeling the release. Which problem does that solve? Are you suggesting that we remove the explicit version number in configure.ac:AC_INIT and instead grab it from the git tag? What does that accomplish?

Thanks,
Andy

[Jannick]

Hi Andy,

thanks for your swift reply. Here a couple of questions important for proper versioning, in particular, which I think reveal the issues easily:

1. In which git commit was version x.y.z of extension E released?
2. How do you derive the git commit a snapshot of extension E published on SF is based on? How do you know that the content of a snapshot file of extension E is different from the previous downloaded one due to a relevant git commit?
3. What is the best way to form a (dirty) version string for each E on each commit which establishes a (chronological) total order on the set of (dirty) version strings (cf., e.g., git describe --tag)?

For repos with one single project the issues above it is pretty much standard to add release tags to the git repo. Same for this one – namely a repository with multiple projects/extensions with not necessarily identical release version strings x.y.z – the only difference would be to necessarily add the extension name to the tag name in a standardized fashion; that’s all.

To your questions (which partly answer mine):

• Yes – add a git tag for each E and its latest release. Going forward add a tag for each release. Tag names should follow a convention containing the extension name and the release number string. Any tag type as preferred.
• No – version string in configure.ac:AC_INIT not changed on git, only with new release (i.e. no change). (This gives an implicit chance to validate that the version string in AC_INIT and the latest git tag corresponding to E match and are in sync.)
• And in addition yes – In snapshots change version string in configure.ac:AC_INIT to something meaningful if version dirty (e.g. <last release version string>-r<number of commits relevant for this extension since last release>-g<short git hash> or something like this autoconf and friends are happy with).

Then git can do all the version house-keeping.

Thanks,
J.

[Andrew J. Schorr]

I have no particular objection to attempting to add tags for releases, but I don't see why it particularly matters, in the sense that there are almost no downloads of any of this stuff anyway. Is anybody actually using the snapshot releases? The stats show zero downloads for those. And frankly, there are almost no downloads of any of the released extensions either. So it seems like we're talking about adding more administrative burden for a project that almost nobody uses.

Jürgen created the snapshot infrastructure, so I leave it to him to investigate whether those could be enhanced in this way. Maybe a first step would be to include the version number in the snapshot name. But why would anybody download the snapshots anyway? If not satisfied with the released version, wouldn't one just grab the git tree? As far as I know, there are no meaningful changes that haven't been released, except for the reclen extension which hasn't been released yet.

Just to test, I pushed a gawk-xml-1.1.1 tag to the repo. Is that what you have in mind?

Regards,
Andy

[Jannick]

First of all, sorry for the late reply.

Yes - the tag gawk-xml-1.1.1 is exactly what I meant. Thanks!

git provides ample features to create these tags within a couple of lines, so not a real burden as far as I can tell. Instead of putting the version number into the snapshot name (which would be redundant information and might interfer with identifying the latest snapshot file once the version number changes), the dirty git version could be put into an additional package file called, e.g., VERSION or simply plugged into the version info in AC_INIT (provided autoconf is happy with the format) where it should end up anyways. Again, what should be accomplished is to be able to identify the commit the snashot is based on.

There is one fundamental difference between the snapshots and the git tree: symbolic links in the git tree are resolved in the snapshots. Cloning the git tree might not handle symbolic links properly (not because of a git config issue, but because of the local system (in)capabilities to create symbolic links).

Meanwhile I am able to work around both issues. Nevertheless I believe extensions offered in this package are really valuable, but are for some reason not so widely known.

Thanks again,
J.

[Andrew J. Schorr]

On Sat, Sep 12, 2020 at 07:05:59AM -0000, Jannick wrote:

First of all, sorry for the late reply.

No worries. I'm sure we're all pretty busy with other issues.

Yes - the tag gawk-xml-1.1.1 is exactly what I meant. Thanks!

You're welcome.

git provides ample features to create these tags within a couple of lines, so
not a real burden as far as I can tell.

It's not a big burden. It's just a question of remembering to do it.

Instead of putting the version number
into the snapshot name (which would be redundant information and might interfer
with identifying the latest snapshot file once the version number changes), the
dirty git version could be put into an additional package file called, e.g.,
VERSION or simply plugged into the version info in AC_INIT (provided autoconf
is happy with the format) where it should end up anyways. Again, what should be
accomplished is to be able to identify the commit the snashot is based on.

Jürgen set up the snapshot mechanism, so I'm going to leave it to him
to address this issue.

There is one fundamental difference between the snapshots and the git tree:
symbolic links in the git tree are resolved in the snapshots. Cloning the git
tree might not handle symbolic links properly (not because of a git config
issue, but because of the local system (in)capabilities to create symbolic
links).

That's a good point.

Meanwhile I am able to work around both issues. Nevertheless I believe
extensions offered in this package are really valuable, but are for some reason
not so widely known.

I'm glad to hear that you find them useful. It's been a lot of work over
the years. I guess most people use Python these days, but I still find
that gawk is better suited to some tasks.

Regards,
Andy