On Friday 19 September 2008 00:02:37 Magnus Holmgren wrote: > 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. :-) > Hey, I'm not him! I was just giving my two cents. I like to learn and thus like answers like yours :), but you said "You shouldn't be afraid of epochs" and I've never used one! About Knuth... well, you can always add a dot before each decimal he adds ;)
Attachment:
signature.asc
Description: This is a digitally signed message part.