IIRC, there was a suggestion of giving pre-release packages -0.* release numbers, and switching to -1 for the initial release...
Now, I can *live* with that (but not especially *like* it). What about pre-test updated versions (after a package has been officially launched and is part of the dist)? [Also, 'REL = 0.x' might break the generic package build script; I'm not sure]
Worse, my pretest versions of libtool are based on *different* CVS snapshots. So they differ not only in REL, but also in VER, from the packages on the cygwin mirrors.
Yes, there are ways around even THAT. Let VER change as it must, but make sure that all pre-test RELs are 0.x. Then bump to -1,2,3,whatever when uploading to the cygwin mirrors.
But that seems like an awful lot of trouble, simply because a few people prefer (a) initial "official" packages start at REL=1, and (b) official packages progress in monotonic, uniform REL #s with no gaps.
IMO, that's simply insane -- no linux distribution does that. You might see foo-1.3.2-2 in rawhide, followed by -4, then -9, and then -11 shows up in the next official Red Hat. Nobody complains. And the post-release security fix for foo is -13, not -12. Big Freaking Deal.
Oh, crap. Are we in another interminable packaging debate?
--Chuck
