diff options
Diffstat (limited to '')
-rw-r--r-- | tags/e/epoch-changed-but-upstream-version-did-not-go-backwards.tag | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/tags/e/epoch-changed-but-upstream-version-did-not-go-backwards.tag b/tags/e/epoch-changed-but-upstream-version-did-not-go-backwards.tag new file mode 100644 index 0000000..83a8de7 --- /dev/null +++ b/tags/e/epoch-changed-but-upstream-version-did-not-go-backwards.tag @@ -0,0 +1,27 @@ +Tag: epoch-changed-but-upstream-version-did-not-go-backwards +Severity: error +Check: debian/changelog +Explanation: The previous version of this package had a different version epoch + to the current version but the upstream version did not go "backwards". + For example, the previous package version was "1:1.0-1" and the current + version is "2:2.0-1". + . + This was likely an accidental bump or addition of an epoch. + . + Epochs exist to cope with changes to the upstream version numbering + scheme. Whilst they are a powerful tool, increasing or adding an epoch + has many downsides including causing issues with versioned dependencies, + being misleading to users and being aesthetically unappealing. Whilst + they should be avoided, valid reasons to add or increment the epoch + include: + . + - Upstream changed their versioning scheme in a way that makes the + latest version lower than the previous one. + - You need to permanently revert to a lower upstream version. + . + Temporary revertions (eg. after an NMU) should use not modify or + introduce an epoch - please use the <code>CURRENT+reallyFORMER</code> until + you can upload the latest version again. + . + If you are unsure whether you need to increase the epoch for a package, + please consult the debian-devel mailing list. |