version naming for extras apps

Colin Watson cjwatson at ubuntu.com
Thu Dec 30 12:11:30 UTC 2010


On Mon, Dec 27, 2010 at 08:08:08AM -0600, Micah Gersten wrote:
>    On 12/22/2010 02:27 PM, Allison Randal wrote:
>    > In ARB apps, we're getting some non-standard version numbers in
>    > packages like 1.0-maverick1 or 1.0-0extras1. We would like to set
>    > a standard and stick with it.
>    >
>    > Following some discussion on #ubuntu-devel, it seems the best
>    > option is to use no modifier (i.e. 1.0-1). Because extras
>    > packages install in /opt, they'll always be built custom for
>    > Ubuntu, and there's no need to distinguish packages that are or
>    > aren't synced from Debian.
>    >
>    > Sound workable? Any concerns?
> 
>    1.0-1 looks like a Debian version.  If there were no modifier,
>    wouldn't 1.0 be more appropriate?

The "ubuntu" substring was introduced to allow maintainers to inhibit
autosync.  That's its sole semantic content.  As a result, people have
got the idea that versions without that kind of suffix are Debian
versions - but I don't think there's any real reason to perpetuate that
idea.  (If nothing else, it confuses people about what that suffix means
in Ubuntu, which is occasionally a problem!)

"1.0" would be inappropriate since that's a native version number, which
comes with special semantics in dpkg-source (e.g. no .diff.gz) - in
particular it would make it awkward to issue updates without releasing a
new upstream version.

If you're concerned about the package later being introduced to Debian
and this causing version conflicts when we try to decommission an extras
package in favour of a distribution package, then I think something like
1.0-0.1, 1.0-0.2, etc. would be fine - the only thing that would need to
be mandated here is that the revision part should be less than 1.

In general I feel that we should be careful not to mandate too much in
version numbers, because they do need to be human-readable and at least
somewhat human-memorable from time to time and excessive requirements
tend to produce painfully long version numbers.  We should keep it
simple.  There's a reason to include a revision part, and there *may* be
a reason to keep the revision part less than 1.  More than that seems
unnecessary, and every extra requirement is going to be an extra drain
on somebody's neurons at some point.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]



More information about the technical-board mailing list