Re: Pending packages status

[Christopher Faylor <cgf at redhat dot com>]

On Fri, Mar 07, 2003 at 02:08:16PM -0500, Charles Wilson wrote:
>Christopher Faylor 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 :}.
>
>>>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:

I'm sure that everyone here gets this point.  There is a *potential*
that the same need that we have for incrementing our standard releases
from -1 to -2, etc.  might be an issue for cygwin-apps.  As is said,
above "I don't remember any confusion caused by the current practice."
I suspect that's because the class of user here (at least for those
doing the review) is a few thousand steps above the standard cygwin
user and can manage with things like "date and time" rather than
-1, -2, -3.

>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...

So, when you upload your changes, adjust the version to the next
released version.

However, I don't really care.  If you think this is the only way for
you to manage your libtool issues, then use whatever works.

>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.

The cygwin user base != the cygwin-apps maintainers.  We are supposed to
be a breed apart.  That's why I don't like the idea of adding, IMO,
silly rules that every "How does it look now" release prior to the
official release needs to be incremented on the off chance that someone
here will be terminally confused and not realize that they might not
have the most up-to-date version.  I can easily imagine the "I can't
review this because you didn't bump the number from -1 to -2" cropping
up.  That just delays the process of getting a package released.

So, as usual, I opt for flexibility (anyone want to guess at my
political leanings?).  I don't think anyone should be forced to use this
method.  If it makes people more comfortable to bump their versions,
then have at it.

cgf