Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5
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..' 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.]
Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5
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..' 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
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
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
[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
