launchpad development|
Size: 1481
Comment:
|
← Revision 3 as of 2012-07-05 20:21:11 ⇥
Size: 1894
Comment:
|
| 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. |
| Line 17: | Line 17: |
| == 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? |
== 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. |
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.
