Charles Wilson wrote:
>>>>>> Pavel:
>>>>>> :) It is not my personal preference, though it may seem like it
>>>>>> is.
>
>>>>> Max:
>>>>> Ah, remembering the recent discussions, I think it *is* exactly
>>>>> your preference :}.
No, this wasn't me.
>>> Max:
>>> Personally, I don't see why the 1st release of a package need be
>>> -1, and I think that, in abstract, a version number should uniqely
>>> identify a version.
>>>
>>> On the other hand, I don't remember any confusion caused by the
>>> current practice.
>
>> cgf:
>> I don't have strong feelings about this other than that I think it
>> would be odd for the first release of a pacakge to be bushwa-1.10-15 and,
>> given some of the packaging discussions here, that is entirely
>> possible. I like being able to look at an announcement and figuring
>> out from the subject if this is a recent release or not.
>>
>> Given that we haven't had any problems with starting out at 1, I
>> think we should continue to work that way.
>
> Yep, IIRC it *was* Pavel's personal preference. It cetainly isn't
> mine. I agree with Max: packages should be uniquely identified, to
> avoid
> confusion *during the prerelease phase*. Imagine:
>
> "Bob, there's a proplem with your foo-1.3.2-1 package"
> "That's fixed in the third release of foo-1.3.2-1"
> "Wait, Bob, I thought I was using the third release. Are you sure?"
> "Nope, you're right -- it's the *fourth* release that fixes the
> problem. Here's the package md5sum..."
> "Um, bob, I just downloaded foo-1.3.2-1 and it has md5sum xxxx. Is
> that newer, or older than the mythical fourth release?"
> "Yeah, sorry about that. I gave you the md5sum of the fourth
> pre-release. I expected that you would simply compare it to the
> md5sum
> of the package you've been complaining about (#3 ?). However, you
> can't download the #3 nor #4 prereleases anymore. We're up to the
> sixth pre-release, and THAT is what you just downloaded..."
>
> This is especially true in my case, since for autotool releases I tend
> to put them up on my website in setup-compatible form prior even to
> "test:" releases on the cygwin mirrors. I *need* to keep pre-release
> and pre-test versions unique if there have been any changes in them.
> Or
> I'll hork off my testers...
>
> As far as chris's comments go, he is right that we haven't yet had too
> many problems -- because most pre-release packages have not been
> "setup-installable". Thus, no problems (except for communication
> issues, as described above).
>
> I expect that as the cygwin userbase grows(*) that both of these
> conditions will change. (*) And recent evidence on the mailing list
> suggests that the cygwin userbase IS growing.
I have a suggestion:
foo-1.0-0.1
foo-1.0-0.2
foo-1.0-0.3
foo-1.0-0.4 << ok, it's ready
foo-1.0-1 << maintainer rebuilds the package with release=1,
and sends a 'Please upload' email
Max.
