Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently I've started packaging software with fpm. The public makefiles can be found on bitbucket.

But I've a problem with version numbers. When I'm generating a package for e.g. the fish-shell I would have to make clear, that the original version of the package hasn't changed, but that this would be the e.g. second package I've generated, so that it can replace the previously generated package.

Is there a best practice or convention?

share|improve this question
up vote 1 down vote accepted

The field is :


          This part of the version number specifies  the  version  of  the
          Debian  package  based  on the upstream version.  It may contain
          only alphanumerics and the characters + . ~  (plus,  full  stop,
          tilde)  and  is compared in the same way as the upstream_version

          It is optional; if it isn’t present  then  the  upstream_version
          may not contain a hyphen.  This format represents the case where
          a piece of software was written specifically to be turned into a
          Debian  package,  and so there is only one "debianisation" of it
          and therefore no revision indication is required.

          It is conventional to restart the debian_revision  at  ’1’  each
          time time the upstream_version is increased.

          Dpkg  will  break the version number apart at the last hyphen in
          the string (if there is one) to determine  the  upstream_version
          and  debian_revision.  The absence of a debian_revision compares
          earlier  than  the  presence  of  one   (but   note   that   the
          debian_revision  is  the  least  significant part of the version


share|improve this answer
So my version for fish should look like this? fish_1.23~git.7abf6c71ad113affcfbb101c80e309d1aaa4bddb~brejoc4 – brejoc May 6 '13 at 21:13
It is not probably a good thing to do as your revision number will not be strictly increasing. It would recommend using the date instead, for instance. – Thomas Moulard May 7 '13 at 8:41
brejoc - the git commit number is one possibility. while i like @Thomas's idea about date stamping your build number you run in to needing to respin loads of packages if it's a common dependency (or rebuild lots of stuff with a >= if it's not already there) so you don't have loads of mismatched build dependencies (just search the site here for dependency problems and look at how many have dates in the version numbers) – RobotHumans May 7 '13 at 10:14
Well if you intend to support upgrade through unstable / git tagged experimental version, you still need to have an order in your package versioning scheme which is not the case when using Git commit number... As for dates as version number, see Debian policy 4.1: – Thomas Moulard May 7 '13 at 11:53
Just to be clear, I wasn't saying you were wrong or disagreeing. I was saying something about why versioning policy is relatively gray. – RobotHumans May 7 '13 at 19:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.