version naming convention
I would like to make the suggestion that future releases of Hugs are made with a version naming convention that is more sort friendly. The current "MonYear" versioning scheme is problematic for packagers. ie the current release would be better called say "200311" (using Debian's hugs98 package versioning scheme) than "Nov2003", since this sorts much more easily. Jens
"Jens" == Jens Petersen
wrote on 5th Jan:
Jens> I would like to make the suggestion that future Jens> releases of Hugs are made with a version naming Jens> convention that is more sort friendly. The Jens> current "MonYear" versioning scheme is problematic Jens> for packagers. Jens> ie the current release would be better called say Jens> "200311" (using Debian's hugs98 package versioning Jens> scheme) than "Nov2003", since this sorts much more Jens> easily. Does this sound reasonable? Any comments from the maintainers? Jens
"JP" == Jens Petersen
writes:
"Jens" == Jens Petersen
wrote on 5th Jan: Jens> I would like to make the suggestion that future Jens> releases of Hugs are made with a version naming Jens> convention that is more sort friendly. The Jens> current "MonYear" versioning scheme is problematic Jens> for packagers.
Jens> ie the current release would be better called say Jens> "200311" (using Debian's hugs98 package versioning Jens> scheme) than "Nov2003", since this sorts much more Jens> easily. JP> Does this sound reasonable? Any comments from the JP> maintainers? Errm, still no response. :-\ Sorry, I should probably have explained that the reason for asking is to resolve the following Fedora Extras packaging issue: https://bugzilla.fedora.us/show_bug.cgi?id=840 and https://bugzilla.fedora.us/show_bug.cgi?id=842 To summarize, basically the problem is that the package version may end up being versioned at 0.0 unless upstream (ie the Hugs maintainers here) agree to some improved (machine friendly) version numbering scheme like YYYYMM instead. So some kind of response would be greatly appreciated to speed up inclusion of hugs98 at the fedora.us repository. :-) Also any help with QA'ing the hugs98 package for Fedora would be great. :-) Jens
Jens Petersen wrote:
[...] To summarize, basically the problem is that the package version may end up being versioned at 0.0 unless upstream (ie the Hugs maintainers here) agree to some improved (machine friendly) version numbering scheme like YYYYMM instead. [...]
I would be even more happy with the common major.minor numbering scheme, with the usual even (= stable) / odd (= unstable) distinction of the minor version number, see e.g. the Linux kernel, GHC,... Ross, Sigbjorn? Cheers, S.
On Sat, Feb 21, 2004 at 08:43:48PM +0100, Sven Panne wrote:
Jens Petersen wrote:
[...] To summarize, basically the problem is that the package version may end up being versioned at 0.0 unless upstream (ie the Hugs maintainers here) agree to some improved (machine friendly) version numbering scheme like YYYYMM instead. [...]
I would be even more happy with the common major.minor numbering scheme, with the usual even (= stable) / odd (= unstable) distinction of the minor version number, see e.g. the Linux kernel, GHC,... Ross, Sigbjorn?
I don't mind YYYYMM -- less of a break with tradition, or YYYY-MM (though that might force an epoch on Debian). Note that snapshots are already versioned YYYYMMDD -- you'd probably want a separate package if you packaged them (as Isaac does for Debian).
"RP" == Ross Paterson
writes:
RP> On Sat, Feb 21, 2004 at 08:43:48PM +0100, Sven Panne RP> wrote: >> Jens Petersen wrote: >> >the package version may end up being versioned at >> >0.0 unless upstream (ie the Hugs maintainers here) >> >agree to some improved (machine friendly) version >> >numbering scheme like YYYYMM instead. [...] >> I would be even more happy with the common >> major.minor numbering scheme, with the usual even (= >> stable) / odd (= unstable) distinction of the minor >> version number, see e.g. the Linux kernel, >> GHC,... Ross, Sigbjorn? Sounds reasonable. :-) RP> I don't mind YYYYMM -- less of a break with RP> tradition, or YYYY-MM (though that might force an RP> epoch on Debian). For rpm packaging YYYYMM is preferrable to YYYY-MM, since rpm uses "-" as a field separator (<name>-<version>-<release>). Thanks, Jens
participants (3)
-
Jens Petersen -
Ross Paterson -
Sven Panne