[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