Hi,

I'm developing a non-native package as both, Upstream and Debian package
maintainer.

It's common that I've not yet decided what will be the new upstream
version number and hence add "+dev" to the previous release's upstream
version number.

But in that case, lintian always considers this to be something like a
release candidate:

W: xen-tools: rc-version-greater-than-expected-version 4.4+dev > 4.4 (consider using 4.4~dev)

Both, the warning and especially the advice are wrong here.

Relevant changelog extracts causing this:
---snip---
xen-tools (4.4+dev-1) UNRELEASED; urgency=low

  * Apply patch by Adrian C. (anrxc) to allow to override hooks in
    /usr/share/xen-tools/*.d/ with hooks in /etc/xen-tools/hooks.d/.
    Thanks! (Also add /etc/xen-tools/hooks.d/ to debian/dirs.)
  * Ignore cover_db directory in t/perl-syntax.t.

Thanks for the bug report.

* Axel Beckert <abe@debian.org>, 2013-12-15, 17:56:

The only strings that currently trigger
rc-version-greater-than-expected-version are "rc", "alpha", "beta",
"pre", "preview", "prerelease" and "dev". I agree that we should delete
"dev" from that list.

Jakub Wilk <jwilk@debian.org> writes:

Not that I have time to implement this at the moment, but an orthogonal
improvement that we could also make would be to look back in the changelog
and see if the version number, despite having one of those strings in it,
is larger than the last upstream version.  That would let us catch:

    4.4 -> 4.4-alpha1 -> 4.4-alpha2 -> 4.5

which some (annoying) upstream might want to do.  Since 4.4-alpha1 is
larger than 4.4 and 4.4 existed previously in changelog, we would assume
the packager knew what they were doing and wouldn't complain.

If we had this in place, the dev problem wouldn't have happened, and we
might even be able to reintroduce dev into that list if, at some point in
the future, some other upstream wants:

    4.4 -> 4.5dev1 -> 4.5dev2 -> 4.5

Hi,

FYI dev was removed from the list in #732246.


Regards,