Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5

Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5

[Ken Brown]

[Redirected from the main cygwin list.]

On 9/21/2021 3:12 PM, Ken Brown via Cygwin wrote:
> On 9/21/2021 1:55 PM, Brian Inglis via Cygwin wrote:
>> On 2021-09-21 10:58, Ken Brown via Cygwin wrote:
>>> On 9/21/2021 11:29 AM, Brian Inglis wrote:
>>>> so suggest we mandate release 0 for test versions, as that would follow 
>>>> naturally.
>>>
>>> There's no need for that.
>>
>> Maybe it would be a good suggestion then?

 From my point of view as a maintainer, there are two main reasons I use test 
releases.

1. For a package in which I'm also an upstream contributor (like Emacs or TeX 
Live or Cygwin), I might want to make a test release of an upcoming upstream 
release to catch bugs prior to the release.  I generally use release numbers 
like 0.1, 0.2,... for these.

2. If there's a new upstream release of a package that I'm less familiar with, I 
just want to make a standard release, but I might not be confident that there's 
no breakage on Cygwin.  So I start with a test release (with release number 1), 
and if no problems are reported after a few weeks I untest it, keeping the 
release number unchanged.

I personally wouldn't have any use for a release number 0 in either case.

Ken

Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5

[Jon Turney]

On 21/09/2021 20:20, Ken Brown via Cygwin-apps wrote:
> [Redirected from the main cygwin list.]
> 
> On 9/21/2021 3:12 PM, Ken Brown via Cygwin wrote:
>> On 9/21/2021 1:55 PM, Brian Inglis via Cygwin wrote:
>>> On 2021-09-21 10:58, Ken Brown via Cygwin wrote:
>>>> On 9/21/2021 11:29 AM, Brian Inglis wrote:
>>>>> so suggest we mandate release 0 for test versions, as that would 
>>>>> follow naturally.
>>>>
>>>> There's no need for that.
>>>
>>> Maybe it would be a good suggestion then?

Release numbers starting with 0 already have a defined meaning.

They are to be used for upstream pre-release versions

e.g pkg-1.0-0.1.g12345678 is a pre-release of pkg 1.0, since this sorts 
before pkg-1.0-1

See https://fedoraproject.org/wiki/Package_Versioning_Examples, included 
by reference in https://cygwin.com/packaging-package-files.html, for 
some more examples.

>  From my point of view as a maintainer, there are two main reasons I use 
> test releases.
> 
> 1. For a package in which I'm also an upstream contributor (like Emacs 
> or TeX Live or Cygwin), I might want to make a test release of an 
> upcoming upstream release to catch bugs prior to the release.  I 
> generally use release numbers like 0.1, 0.2,... for these.
> 
> 2. If there's a new upstream release of a package that I'm less familiar 
> with, I just want to make a standard release, but I might not be 
> confident that there's no breakage on Cygwin.  So I start with a test 
> release (with release number 1), and if no problems are reported after a 
> few weeks I untest it, keeping the release number unchanged.

Yeah.  Brian's suggestion doesn't always work in this case.

If we wanted to a test release of pkg after pkg-1.0-5, without any 
upstream changes, it would be pkg-1.0-6, we can't reset the release to 0.

> I personally wouldn't have any use for a release number 0 in either case.

Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5

[Brian Inglis]

On 2021-09-21 14:04, Jon Turney wrote:
> On 21/09/2021 20:20, Ken Brown via Cygwin-apps wrote:
>> [Redirected from the main cygwin list.]
>>
>> On 9/21/2021 3:12 PM, Ken Brown via Cygwin wrote:
>>> On 9/21/2021 1:55 PM, Brian Inglis via Cygwin wrote:
>>>> On 2021-09-21 10:58, Ken Brown via Cygwin wrote:
>>>>> On 9/21/2021 11:29 AM, Brian Inglis wrote:
>>>>>> so suggest we mandate release 0 for test versions, as that would 
>>>>>> follow naturally.
>>>>>
>>>>> There's no need for that.
>>>>
>>>> Maybe it would be a good suggestion then?
> 
> Release numbers starting with 0 already have a defined meaning.
> 
> They are to be used for upstream pre-release versions
> 
> e.g pkg-1.0-0.1.g12345678 is a pre-release of pkg 1.0, since this sorts 
> before pkg-1.0-1
> 
> See https://fedoraproject.org/wiki/Package_Versioning_Examples, included 
> by reference in https://cygwin.com/packaging-package-files.html, for 
> some more examples.

Thanks for that pointer and link, but the examples are simple with 
uniform version levels and random strings ordered using sequential 
prefixes.

The upstream bison test versions I was trying while working on some test 
config problems with bison 3.8/3.8.1 e.g.
bison-3.8.1.27-dd6e.tar.xz, bison-3.8.1.29-5c106.tar.xz should they be
3.8.1.27-0.1.dd6e, 3.8.1.29-0.1.5c106 or
3.8.1-0.27.dd6e, 3.8.1-0.29.5c106 or even
3.8.1-0.1.27.dd6e, 3.8.1-0.2.29.5c106 ?

For these multi-level versions, is ls -v or sort -V definitive for 
Cygwin versions, or some other sort?

>>  From my point of view as a maintainer, there are two main reasons I 
>> use test releases.
>>
>> 1. For a package in which I'm also an upstream contributor (like Emacs 
>> or TeX Live or Cygwin), I might want to make a test release of an 
>> upcoming upstream release to catch bugs prior to the release.  I 
>> generally use release numbers like 0.1, 0.2,... for these.
>>
>> 2. If there's a new upstream release of a package that I'm less 
>> familiar with, I just want to make a standard release, but I might not 
>> be confident that there's no breakage on Cygwin.  So I start with a 
>> test release (with release number 1), and if no problems are reported 
>> after a few weeks I untest it, keeping the release number unchanged.
> 
> Yeah.  Brian's suggestion doesn't always work in this case.
> 
> If we wanted to a test release of pkg after pkg-1.0-5, without any 
> upstream changes, it would be pkg-1.0-6, we can't reset the release to 0.
> 
>> I personally wouldn't have any use for a release number 0 in either case.

Makes sense.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5

[Jon Turney]

On 22/09/2021 04:30, Brian Inglis wrote:
> On 2021-09-21 14:04, Jon Turney wrote:
>>
>> Release numbers starting with 0 already have a defined meaning.
>>
>> They are to be used for upstream pre-release versions
>>
>> e.g pkg-1.0-0.1.g12345678 is a pre-release of pkg 1.0, since this 
>> sorts before pkg-1.0-1
>>
>> See https://fedoraproject.org/wiki/Package_Versioning_Examples, 
>> included by reference in 
>> https://cygwin.com/packaging-package-files.html, for some more examples.
> 
> Thanks for that pointer and link, but the examples are simple with 
> uniform version levels and random strings ordered using sequential 
> prefixes.
> 
> The upstream bison test versions I was trying while working on some test 
> config problems with bison 3.8/3.8.1 e.g.
> bison-3.8.1.27-dd6e.tar.xz, bison-3.8.1.29-5c106.tar.xz should they be
> 3.8.1.27-0.1.dd6e, 3.8.1.29-0.1.5c106 or
> 3.8.1-0.27.dd6e, 3.8.1-0.29.5c106 or even
> 3.8.1-0.1.27.dd6e, 3.8.1-0.2.29.5c106 ?

Question is a little unclear, but I think the answer is you are looking 
for is that R should be something like '0.<serial|date>.<hash>'

> For these multi-level versions, is ls -v or sort -V definitive for 
> Cygwin versions, or some other sort?

https://cygwin.com/packaging-package-files.html also describes the ordering.

>  Version and release sort according to the following rules:
> 
>     Contiguous chunks of digits or alphabetic characters are compared
>     Non-alphanumeric separators for these contiguous chunks are ignored
>     Alphabetic chunks sort before digit chunks
>     Digit chunks sort numerically and alphabetic chunks sort lexicographically
>     If all chunks are equal, the string with any suffix remaining is the greater
> 
> A package with a higher version is greater, regardless of the release. When two packages have an identical version, the one with the higher release is greater. 

This is the ordering known as 'rpmvercmp'.

Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5

[Brian Inglis]

On 2021-09-23 07:36, Jon Turney wrote:
> On 22/09/2021 04:30, Brian Inglis wrote:
>> On 2021-09-21 14:04, Jon Turney wrote:
>>> Release numbers starting with 0 already have a defined meaning.
>>> They are to be used for upstream pre-release versions
>>> e.g pkg-1.0-0.1.g12345678 is a pre-release of pkg 1.0, since this 
>>> sorts before pkg-1.0-1

>>> See https://fedoraproject.org/wiki/Package_Versioning_Examples, 
>>> included by reference in 
>>> https://cygwin.com/packaging-package-files.html, for some more examples.

>> Thanks for that pointer and link, but the examples are simple with 
>> uniform version levels and random strings ordered using sequential 
>> prefixes.

>> The upstream bison test versions I was trying while working on some 
>> test config problems with bison 3.8/3.8.1 e.g.
>> bison-3.8.1.27-dd6e.tar.xz, bison-3.8.1.29-5c106.tar.xz should they be
>> 3.8.1.27-0.1.dd6e, 3.8.1.29-0.1.5c106 or
>> 3.8.1-0.27.dd6e, 3.8.1-0.29.5c106 or even
>> 3.8.1-0.1.27.dd6e, 3.8.1-0.2.29.5c106 ?

> Question is a little unclear, but I think the answer is you are looking 
> for is that R should be something like '0.<serial|date>.<hash>'

Thanks Jon,

Sorry I meant to address VERSION and RELEASE, which means none of my 
alternatives are usable, but my first set of alternatives would work, 
with the second test release's serial bumped.

>> For these multi-level versions, is ls -v or sort -V definitive for 
>> Cygwin versions, or some other sort?

> https://cygwin.com/packaging-package-files.html also describes the 
> ordering.

>>  Version and release sort according to the following rules:
>>
>> Contiguous chunks of digits or alphabetic characters are compared
>> Non-alphanumeric separators for these contiguous chunks are ignored
>> Alphabetic chunks sort before digit chunks
>> Digit chunks sort numerically and alphabetic chunks sort 
>> lexicographically
>> If all chunks are equal, the string with any suffix remaining is 
>> the greater

I looked at the calm, setup, ls, and sort code, and they appear similar, 
but I missed the subtlety of alpha before numeric.

The first rule also implies that mixed symbol sets like hashes, hex, or 
encodings generate multiple not usefully comparable chunks.

>> A package with a higher version is greater, regardless of the release. 
>> When two packages have an identical version, the one with the higher 
>> release is greater. 

The Cygwin code also supports a leading /epoch:/ default 0 like Debian.

> This is the ordering known as 'rpmvercmp'.

I noticed the mention of rpmvercmp, but it appeared non-definitive.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]