Re: Problems with gnits standard and git-version-gen
> 1.00rc0 > > Personally, when I see a version number like that, I'm never sure > what it means. Probably the first rc leading up to 1.00, but maybe > it is an rc for 1.01 after 1.00. Well, I have *never* encountered that `1.00rc0' means a release candidate for 1.01. Have you? > And suffixes sort badly in long lists (see, e.g., > http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change your > ways, but since you raised the subject, tossing in my gratuitious > opinion, sorry. :-) For `political reasons' I need a `1.00' in the version string. Otherwise, I would be just happy with 0.99.91 or so. > [...] he included "support" in automake for the extra gnits checks > we were thinking about. That is all. Well, some tests are quite useful. It's just the version number checking that I consider... limited. Anyways, the problem with `git-version-gen' are real. There might be good reasons to have, say 2.17-foobar to indicate a special modification of 2.17, and git-version-gen doesn't like it. Werner
Re: Problems with gnits standard and git-version-gen
For NTP, we have a kinda hard to describe but easy to read mechanism. For development versions (odd-number minor releases) each new "issue" gets a bumped "point number" (major.minor.point). If that issue is a release candidate it gets a "-RC" suffix. For stable versions (even-number minor releases) if we have to make public snapshots and we are currently at 4.2.6p5 (old way, the new way would be 4-2.6.5), we'd either be publishing a -betaN, -RCn, or release upgade. The progression might look like this: 4-6.2.5 4-6.2.6-beta1 (the first beta release that would become 4-6.2.6) 4-6.2.6-RC1 (the first RC for 4-6.2.6) 4-6.2.6 and I note that it doesn't sort well if we go from beta1 to RC1 to beta2 to beta3 to RC2. At that point you'd need to look at the file timestamps. But we do our best to be very careful with changes to the -stable branch so this is very rarely an issue. And normal folks will just wait for the production release. This is not an issue for dev code because we can always bump the point number there to make the order clear, and identify whether or not a tarball is a release candidate or not. H
Re: Problems with gnits standard and git-version-gen
1.00rc0 Personally, when I see a version number like that, I'm never sure what it means. Probably the first rc leading up to 1.00, but maybe it is an rc for 1.01 after 1.00. And suffixes sort badly in long lists (see, e.g., http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change your ways, but since you raised the subject, tossing in my gratuitious opinion, sorry. gnits standard gnits is not a standard of any kind. It was a small group of GNU friends who, some 20+ years ago, wanted to expand on the GNU coding standards (which were not being actively maintained at the time, among other reasons). One of us was Tom Tromey, writing automake at the time. So he included "support" in automake for the extra gnits checks we were thinking about. That is all. If you don't like it, don't use it. No harm will befall you. doesn't allow non-numeric suffixes... Because it's not what rms recommended. That simple. As you may remember, we used to use 1.7a, 1.7b, ..., leading to up a 1.8 release. Someone complained about it, can't remember who, maybe Debian, but anyway, rms devised the .90, .91, ... method to accommodate. And since it's just a version number, many maintainers were happy to just go along with the new program. k
