On torsdagen den 18 september 2008, Noel David Torres Taño wrote: > > > Epochs often cause more problems than they solve, one should not use > > > them too lightweight, as you will never be able to get rid of them > > > again. That 1.4 is after 1.32 (and not 28 releases before) means that > > > upstream seems to use some strange numbering sheme based on decimal > > > fractions. There are good chances this will happen again in the future, > > > so instead of using an epoch, normalizing that to usual natural numbers > > > by making that a 1.40 could have expressed the situation more clearly > > > (and avoid similar problems in the future). But alas, it is to late, > > > the epoch is in the archive, it can never ever go away now... > > > > I agree, I see now that problem is the epoch > > Maybe a package renaming would eliminate epoch? Renaming the package can be used to get rid of the epoch, but will necessitate a transitional package (with a different version number than the new real package), so if you don't have a better reason for renaming it's definitely not worth it. You shouldn't be afraid of epochs, but it would be a bit silly if you had to increment it each time upstream releases a new one-digit minor version, so I suggest that you try to convince upstream that version strings aren't decimal numbers and that subsequent releases should be called 1.4.1, 1.4.2 and so on. (If you succeed you might try to convince Donald Knuth next. :-) -- Magnus Holmgren holmgren@debian.org Debian Developer
Attachment:
signature.asc
Description: This is a digitally signed message part.