⇤ ← Revision 1 as of 2012-07-04 19:27:41
1481
Comment:
|
1485
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
We have tried several default debversion schemes, but none has been entirely successful. We started with {{{0+revno}}}, then bug Bug:652109 inspired us to add debversion. Now, bug:1020983 suggests further changes. | We have tried several default debversion schemes, but none has been entirely successful. We started with {{{0+revno}}}, then bug Bug:652109 inspired us to add debversion. Now, bug Bug:1020983 suggests further changes. |
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 earlier than the next version of the package they are based on
Reasonable users may disagree about this-- are the changes introduced by the next version more important to them than the changes introduced by the recipe build?