aef769614f92 - main - pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases

Ravi Pokala rpokala at freebsd.org
Thu Jan 14 19:09:10 UTC 2021


-----Original Message-----
From: <owner-src-committers at freebsd.org> on behalf of Kyle Evans <kevans at freebsd.org>
Date: 2021-01-14, Thursday at 07:58
To: Emmanuel Vadot <manu at bidouilliste.com>
Cc: Kyle Evans <kevans at freebsd.org>, Renato Botelho <garga at freebsd.org>, src-committers <src-committers at freebsd.org>, <dev-commits-src-all at freebsd.org>, <dev-commits-src-main at freebsd.org>
Subject: Re: git: aef769614f92 - main - pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases

    On Thu, Jan 14, 2021 at 9:48 AM Emmanuel Vadot <manu at bidouilliste.com> wrote:
    >
    > On Thu, 14 Jan 2021 09:44:22 -0600
    > Kyle Evans <kevans at freebsd.org> wrote:
    >
    > > On Thu, Jan 14, 2021 at 9:41 AM Kyle Evans <kevans at freebsd.org> wrote:
    > > >
    > > > On Thu, Jan 14, 2021 at 9:02 AM Emmanuel Vadot <manu at bidouilliste.com> wrote:
    > > > >
    > > > > On Thu, 14 Jan 2021 11:59:25 -0300
    > > > > Renato Botelho <garga at FreeBSD.org> wrote:
    > > > >
    > > > > > On 14/01/21 10:00, Emmanuel Vadot wrote:
    > > > > > > The branch main has been updated by manu:
    > > > > > >
    > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=aef769614f921660cb0262412426034cf5395ae5
    > > > > > >
    > > > > > > commit aef769614f921660cb0262412426034cf5395ae5
    > > > > > > Author:     Emmanuel Vadot <manu at FreeBSD.org>
    > > > > > > AuthorDate: 2021-01-14 12:56:38 +0000
    > > > > > > Commit:     Emmanuel Vadot <manu at FreeBSD.org>
    > > > > > > CommitDate: 2021-01-14 13:00:04 +0000
    > > > > > >
    > > > > > >      pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases
    > > > > > >
    > > > > > >      The current postfix conversions are:
    > > > > > >
    > > > > > >          CURRENT / STABLE -> .sYYYYMMDDhhmmss
    > > > > > >          ALPHAx -> .ax, so 11.3-ALPHA1 becomes 11.3.a1
    > > > > > >          BETAx -> .bx, so 12.1-BETA2 becomes 12.1.b2
    > > > > > >          RCx -> .rcx, so 13.0-RC3 becomes 13.0.rc3
    > > > > > >          PRERELEASE -> .p, so 11.3-PRERELEASE becomes 11.3.p
    > > > > > >          RELEASE -> (nothing), so 12.1-RELEASE becomes 12.1
    > > > > >
    > > > > > Wouldn't it be necessary to add timestamp information on PRERELEASE as
    > > > > > done on CURRENT/STABLE ?
    > > > >
    > > > >  Yes it would, this wasn't one of the reason for the revert but it was
    > > > > brough to me after.
    > > > >  -STABLE should always be .sYYYYMMDDhhmmss even when in the PRERELEASE
    > > > > phase.
    > > >
    > > > I had a chance to play with it a little bit, and my proposal is:
    > > >
    > > > 1.) Drop -PRERELEASE as a non-CURRENT/STABLE versioning scheme in the
    > > > pkg versions
    > > > 2.) Use .plYYYYMMDDhhmmss instead of .sYYYYMMDDhhmmss for
    > > > CURRENT/STABLE (.pl sorts before all others in the pkg version scheme
    > > > quite intentionally)
    > > > 3.) Reinstate all of the others as committed here
    > > >
    > > > This basically works; it's a little kludgy during a release process up
    > > > until the version on -STABLE is bumped up to the next minor if you're
    > > > trying to hop off an alpha/beta/rc back to stable, but I think that's
    > > > acceptable. It's a narrow window in which your slide over to -STABLE
    > > > is considered a downgrade since it gets bumped promptly at the
    > > > conclusion of the release cycle.
    > > >
    > > > root at viper:~/pkg/libpkg# pkg version -t 13.0.a1 13.0.b1
    > > > <
    > > > root at viper:~/pkg/libpkg# pkg version -t 13.0.b1 13.0.rc1
    > > > <
    > > > root at viper:~/pkg/libpkg# pkg version -t 13.0.rc1 13.0
    > > > <
    > >
    > > I omitted the first step, which is arguably the most important one:
    > >
    > > root at viper:~/pkg/libpkg# pkg version -t 13.0.pl2021011313063 13.0.a1
    > > <
    >
    >  Seems good to me, now if only I knew what 'pl' stands for that would
    > be good :)
    >  Can you do a patch or should I ?
    >

    Phew, I'm glad I'm not the only one. :-) I'm going to call it
    "(pl)aceholder," but I hadn't seen any indication of its actual
    meaning when it arrived back in '04
    (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=56961)

Unless there's already code looking for "pl", I would suggest "pr" for prerelease.

-Ravi (rpokala@)

    I'll whip up a patch later today.

    Thanks,

    Kyle Evans




More information about the dev-commits-src-all mailing list