Reply to comment
It is a common problem with packagers. Developers release a package 0.4, then release a 0.5a (or 0.5pre1 or 0.5rc1) and then release the stable 0.5. Of course, when packaging you have to foresee such problems and maintain a proper upgrade path from 0.4 to 0.5pre1 to 0.5rc1 and to 0.5. Often that means finding the meaning of a release string.
Now, dependency resolvers have a certain way of doing things and a packager then needs to translate version from 0.5pre1 to something like 0.5-0.1.pre1 and abuse the release tag to maintain a sensible upgrade path. Not necessarily something users may understand correctly.
Problematic cases are not limited to the above example, I have seen projects that prefer a timestamp, like 041296 (you figure out if this is 1996 or 2004) or slightly better 20070317. As a packager you can expect some day that a 1.0 release is made (much like wine changed course, but we are still waiting for th 1.0 release) so we often translate it to something like 0.0.19961204 or 0.0.20070317 so that we are prepare for the 0.1 release. (Even when developers explicitely stated they were going to use timestamps forever)
Very popular are the nearing-hundred versions, going from 0.5 to 0.5.91 to 0.5.99 before going to 0.6. Or worse, negative version numbers going from 0.5 to 0.6.-9 on to 0.6.-1 and 0.6 !
But today I came across something I wasn't sure if it was genius, or madness ? I haven't figured it out. Inkscape goes from 0.45.1 to 0.45.1+0.46pre1 before going to a final 0.46. The advantage of doing this obviously is that you do not have to remap versions into the Release-tag, but you can use the version (including the plus sign) verbatim in your SPEC file.
Does it look more ugly than abusing the Release-tag, or instead does it shine in simplicity and descriptiveness ? I think I have to sleep on this one, but it surely is another creative solution :-)
(I do agree it looks a bit weird, but maybe it could become a new convention among packagers and developers ?)