[Deepsea-users] DeepSea version number management and packaging

Lenz Grimmer lgrimmer at suse.com
Tue Nov 28 07:30:41 MST 2017


Hi Joao,

On 11/27/2017 03:05 PM, Joao Eduardo Luis wrote:

>> I'm still not convinced that adding git hashes to the actual version
>> number is a good idea, but that's likely a bikeshed painting
>> discussion :)
> 
> For versions *we* release, this is somewhat pointless, as long as we tag
> the release and build from it.

Which should be established practice, yes. For each public/official
release, there should be a corresponding git tag, as well as a tarball
containing the sources relating to that revision.

> Having the git sha in the version however becomes really useful when
> figuring which version is being run by the user. It may or may not be
> the version we are releasing.

But does it have to be part of the actual version number? The git hash
does not really add any direct value to users just curious about which
version they're using.

Can't the git hash that particular build is based on be stored in a file
like version.txt? This would have the benefit of other tools being able
to query the version number without having to go through the packaging
system.

> Users won't necessarily be running a tagged version. They may be running
> from a package generated by us on OBS, or from something they built
> locally, or from their own clone on OBS, or whatever else. It's
> important to know how far they diverted, and on which commit they are at
> when diagnosing issues.

The approach of storing the git revision in version.txt of course only
works if you have a standardized process for building the "source
tarball" that is the basis for building actual RPM package.

If you have tools that perform a direct "git-archive" (like OBS), this
does not work, and the only option for storing the git revision is as
part of the archive's name, which is somewhat brittle and hard to use
from within the application.

To share how we do this in openATTIC: we maintain the version number in
version.txt. It actually points to the *next* public release version, so
e.g. as soon as oA 3.6.0 has been released, we bump up the version
number in version.txt to 3.6.1, to indicate that this is the version
we're currently working on:

$ cat version.txt
[package]
VERSION = 3.6.1

For creating a tarball package, we have a script named "make_dist.py",
which is capable of building both "release" tarballs as well as
"snapshot" tarballs from a given git revision/branch.

When building a source distribution tarball, version.txt is updated with
some additional information before it is added to the tarball:

[package]
VERSION = 3.6.1
STATE = snapshot
REV = af5d766e3036b3c439aa668428342bb8cd0528de
BUILDDATE = 201711271141

The variables are hopefully self-explanatory; STATE could be either
"snapshot" or "release" (which indicates an official release build).

The script also updates the version number in the RPM spec file included
in the tarball, so it matches the version string of the source tarball.

When building a snapshot, the version number of the tarball is extended
with a time stamp, e.g. openattic-3.6.1~201711271141.tar.bz2. This
ensures that you can easily update from one snapshot to the next one.
Both RPM and dpkg understand this versioning scheme and also are aware
of the fact that "3.6.1" (the final release) is actually newer than
"3.6.1~<timestamp>" (a snapshot of the 3.6.1 development).

This approach has served us very well so far, and also makes it possible
to query oA for it's version number via the REST API, for example.

> It may even be useful for downstreams, to efficiently check whether a
> consumer of a given package is running the vanilla or a patched version,
> simply by comparing their git hash to whatever is the hash for that
> version.

Absolutely, agreed - but only if all patches applied to this package are
actually tracked in a git repo, and not applied by RPM at build time...
(but our approach using version.txt also is prone to that).

Lenz

-- 
SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.suse.com/pipermail/deepsea-users/attachments/20171128/f5dfa2d3/attachment.sig>


More information about the Deepsea-users mailing list