Package with version *and* timestamp?

[ringods]

My initial packages just had the timestamp detected via git as their version. For some of our work, we have parallel branches in which we want to identify the "major" release, but append the timestamp for consecutive builds.

Is this possible with swaddle? I tried setting the version in swaddle.conf but then the timestamp is gone. It seems to be one or the other.

E.g in a git-flow setup

• On feature branch with version 1.4.1:
  • mypkg-1.4.1-2015.0511.1237+1.deb
  • mypkg-1.4.1-2015.0512.1427+1.deb
• On development branch with version still at 1.4.0:
  • mypkg-1.4.0-2015.0418.1121+1.deb
  • mypkg-1.4.0-2015.0421.1541+1.deb
• On master branch with version 1.3.0:
  • mypkg-1.3.0-2015.0405.0810+1.deb
  • mypkg-1.3.0-2015.0417.2254+1.deb

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

The examples above show the version I set in swaddle.conf as the upstream_version and the date+iteration as the debian_revision. Would match nicely. :smile:

[raphaelcohn]

I'm not sure I'm exactly clear on what you're asking for me. However, I can go over how things work currently. Right now the version is one of two things:-

• If not explicitly specified (swaddling/swaddling.conf and swaddling/swaddle/package.conf for all packages, or on a per-package-kind basis) it defaults to a 3 part timestamp which is the last file checked into git. For my uses, this is quite correct
• If specified, then it's whatever you want it to be
• The iteration count defaults to 1 and is set to 2 if there's a non-checked-in change in the repository
• The timestamp is used to make all the files that get packaged have the same timestamp. This means identical builds of packages are comparable using sha-2, unless using zips (which embed a build timestamp in the package footer) or packaging JARs (same problem), and released packages work properly with HTTP headers.

The challenges with versioning are:

• that everyone has their own approach;
• the version works for all the package kinds swaddle creates
• if generating versions, how to handle repositories where not everything is checked in (this is where the iteration counter default comes in)
• what is a version number? How do I generate one? How do I make the same source and same build have the same version? Do I check it in? (!NO!)

Speaking personally, and from very long experience of managing massively complex projects, using date based versioning which matches git revision is preferable, since it makes a very rapid way to diagnose in production where an asset has come from. It also monotonically increases. What I no longer favour is any sort of semantic versioning, etc. In practice, it's completely meaningless, because it's the downstream users who determine if a change is breaking, and, with a large internal set up (or the internet at large), impossible to know (cf soname versioning - just as broken). I treat every package revision of anything now as 'breaking' - hence my current project to build a secure, built from source in git Linux which rebuilds downstream components on every change (it's a nightmare to do, because the GNU autocruft is hideous). However, I want you to be free as a swaddle user to use whatever versioning you want, provided it's sane and doesn't cause pain (or insecurity) to users. What swaddle won't support explicitly is build revisions - doing the same build, with the same source, should have the same version (incl iteration). This is something a lot of CI servers get wrong. It's also occasionally hard, because some linkers and the java jar embed a build timestamp.

Specifically in the Debian world, things are a little more refined than most versioning approaches. However, if one is producing one's own packages, I ought to point out I believe there is no upstream revision. And it also gets a little funky with remixes like Ubuntu, which do strange things to the iteration count.

So here are some proposals:-

• Could you achieve what you want with a more complex iteration count (I've not tested them, but non-numeric values should work)?
• Could you achieve what you want with a 'version prefix' (ie we compute our version, you specify yours)
  • eg there's version_prefix and version; the former defaults to empty, the later to the 3 part timestamp
  • if you specify version_prefix, we insert the hyphen for you? Or you specify the hyphen?
  • version_prefix is == upstream_version?
• There's a command line option to take a version? (I'm less keen on this, it'd be easy to screw up)
• It is possible to break out the version setting into a fragment in swaddle.conf.d, so you could have a file that contains just the one line to set the version, and cat <<-EOF this in a pre-build step (and use .gitignore)?