launchpad development
Recipe Build Debversioning
We have tried several default debversion schemes, but none has been entirely successful. We started with 0+revno, then bug 652109 inspired us to add debversion. Now, bug 1020983 suggests further changes.
In order to avoid flip-flopping, let's look at the desires:
The debversion must be reasonably unique
This is a requirement of the dpkg ecosystem. Each debversion is expected to be used only once.
The debversion should indicate that it was created as a recipe build
It is convenient for users to be able to distinguish between official packages and recipe builds. Recipe builds that are official packages can use a non-default debversion template.
Recipe builds should sort later than the package they are based on
If a user has added a PPA containing recipe builds, one may assume the recipe builds contain some changes they consider desirable. Therefore, the recipe-build version should take priority.
Exception: with nesting, the packaging is distinct from the code, and so the code may actually be older than the packaging version. Reasonable users may disagree about which version is preferable in this case. See below.
Recipe builds should sort later than the next version of the package they are based on
If the user has installed a recipe build, they have stated a clear preference for a variant package. We should not silently replace it with the next version of the standard package, because that could remove functionality. It's easy to imagine that the variant package would lag the standard package slightly, causing the user to install next version of the standard package, and the next day, install the next version of the variant package. Such variation in functionality would be undesirable. So it seems the default for builds should supersede standard packaging.
