Dev/Versioning Format Conventions

< Dev

Versioning Format Conventions[edit]

Package Version Numbers[edit]

For individual packages (list) developed under the Whonix umbrella, currently happens as follows. More or less as a custom, as a convention. Not by a finalized master plan.

1) Git commits to specific packages are being made.
2) Eventually, more git commit to specific packages are being made.
3) When the maintainer of the package feels, that substantial changes have been made, the debian/changelog version will be bumped. This is done using make deb-uachl-bumpup, which updates changelog.upstream and bumps debian/changelog version. The commit message mostly is "bumped changelog version". Let's call this state by convention the finalized version commit to ease discussing this.
4) Eventually, if someone requested it or if that version is supposed to become a Whonix (developers-only, testers-only or stable) release, git tags will be signed. [1]
5) Development continues. More git commits are being made. At this point, what debian/changelog version says will be false, outdated. This is non-ideal, but no one suggested how it could be done any better.
6) Back to 1).

If other substantial changes happen, such as if the generic makefile is being updated, this also deserved bumping the version number.

The format is: [epoch:]upstream_version[-debian_revision] as defined per Debian Policy, Version.

Epoch is currently set to 3 for historic reasons.

The very first upstream version is usually 0.1. Usually incremented by 0.1 (i.e. for example from 1.9 to 2.0 and so forth). Usually means, at the discretion of the package maintainer different upstream versions can be used.

Debian revision is currently always set to 1 and not in use because most changes are not packaging changes, but upstream package changes and because upstream author currently equals packager and because packages are not uploaded to Debian yet where one would just fix the packaging but leave the upstream version as is.

Whonix Version Numbers[edit]

The Whonix main source code / build script references all the individual packages using git submodules. It points to specific git commits of the individual packages.

For (testers-only and stable) releases, by convention, all packages must point to finalized version commits. [2] This is useful so users can refer to package versions as dpkg reports them. (Example: dpkg -l .) Otherwise it would be version 3:0.8-1 + git~5 or something like that, which would be very unusable. This does not does not apply for developers-only releases, because those are sometimes only used for quick tests to see if the build script still runs through without any issues.


  1. To ease this, the following commands will be used. To sign the git tag.
    make git-tag-sign

    To verify that the git tag can be verified and that the git hash it points to is itself a signed git commit.

    make git-verify

    This is not a requirement, these commands are just shortcuts.

  2. finalized version commit as defined above.

No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.

Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.

Random News:

Want to make Whonix safer and more usable? We're looking for helping hands. Check out the Open Issues and development forum.

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)

Whonix is provided by ENCRYPTED SUPPORT LP. See Imprint.