[ANNOUNCEMENT] Updated: dash 0.5.11.5
Jon Turney
jon.turney@dronecode.org.uk
Tue Sep 21 20:04:14 GMT 2021
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.
More information about the Cygwin-apps
mailing list