* Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5 [not found] ` <67547c41-55c4-743a-1194-3d47bb5562cd@cornell.edu> @ 2021-09-21 19:20 ` Ken Brown 2021-09-21 20:04 ` Jon Turney 0 siblings, 1 reply; 5+ messages in thread From: Ken Brown @ 2021-09-21 19:20 UTC (permalink / raw) To: cygwin-apps [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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5 2021-09-21 19:20 ` [ANNOUNCEMENT] Updated: dash 0.5.11.5 Ken Brown @ 2021-09-21 20:04 ` Jon Turney 2021-09-22 3:30 ` Brian Inglis 0 siblings, 1 reply; 5+ messages in thread From: Jon Turney @ 2021-09-21 20:04 UTC (permalink / raw) To: cygwin-apps 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5 2021-09-21 20:04 ` Jon Turney @ 2021-09-22 3:30 ` Brian Inglis 2021-09-23 13:36 ` Jon Turney 0 siblings, 1 reply; 5+ messages in thread From: Brian Inglis @ 2021-09-22 3:30 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5 2021-09-22 3:30 ` Brian Inglis @ 2021-09-23 13:36 ` Jon Turney 2021-09-23 17:08 ` Brian Inglis 0 siblings, 1 reply; 5+ messages in thread From: Jon Turney @ 2021-09-23 13:36 UTC (permalink / raw) To: cygwin-apps 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'. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5 2021-09-23 13:36 ` Jon Turney @ 2021-09-23 17:08 ` Brian Inglis 0 siblings, 0 replies; 5+ messages in thread From: Brian Inglis @ 2021-09-23 17:08 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-09-23 17:08 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <announce.20210919172710.46999-1-Brian.Inglis@SystematicSW.ab.ca> [not found] ` <87ee9j92m0.fsf@Otto.invalid> [not found] ` <6afad1d6-d3ea-7903-151e-e50f6a9a98ab@SystematicSw.ab.ca> [not found] ` <5212e253-7778-f034-d1a9-c4acf0feac40@cornell.edu> [not found] ` <04aa78a5-c925-b04f-52aa-69111b919444@Shaw.ca> [not found] ` <67547c41-55c4-743a-1194-3d47bb5562cd@cornell.edu> 2021-09-21 19:20 ` [ANNOUNCEMENT] Updated: dash 0.5.11.5 Ken Brown 2021-09-21 20:04 ` Jon Turney 2021-09-22 3:30 ` Brian Inglis 2021-09-23 13:36 ` Jon Turney 2021-09-23 17:08 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).