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
