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

[kevans]

Summary

The current postfix conversions are:

CURRENT / STABLE / PRERELEASE, 12.x-CURRENT becomes 12.snapYYYYMMDDhhmmss
ALPHAx -> .ax, so 11.3-ALPHA1 becomes 11.3.a1.YYYYMMDDhhmmss
BETAx -> .bx, so 12.1-BETA2 becomes 12.1.b2.YYYYMMDDhhmmss
RCx -> .rcx, so 13.0-RC3 becomes 13.0.rc3.YYYYMMDDhhmmss
RELEASE -> (nothing), so 12.1-RELEASE becomes 12.1
RELEASE-pX -> pX, so 12.1-RELEASE-p1 becomes 12.1p1

Note that for development branches we will start to drop the minor version
component entirely, which more closely matches how these branches are
physically named (stable/NN).

snap is a new prefix that was added to pkg in [0], which is simply a more
verbose version of the current ".s" used.

[0] https://github.com/freebsd/pkg/pull/1929

Submitted by: rene (original, original version)

[kevans]

(The physical "Author" on this patch will be set to manu, for proper attribution of "original version" while the original-1 version is recorded in "Submitted by")

[gjb]

I *think* RELEASE being 12.1 (without a suffix) should be 12.1-RELEASE, since for SAs/ENs, we will likely need to append a patch number (i.e., 12.1-RELEASE.1 or something).

I do not see any concerns with the rest of the proposed change, either way.

[kevans]

In D28167#629467, @gjb wrote:

I *think* RELEASE being 12.1 (without a suffix) should be 12.1-RELEASE, since for SAs/ENs, we will likely need to append a patch number (i.e., 12.1-RELEASE.1 or something).

I do not see any concerns with the rest of the proposed change, either way.

I should revise the message to mention this, but this is accounted for in the form of what we'd typically call a port revision:

root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE -V PKG_VERSION
13.0
root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE-p1 -V PKG_VERSION
13.0_1
root@viper:/usr/src# pkg version -t 13.0 13.0_1
<

[gjb]

Thank you for clarifying. I have no objection, then.

[kib]

In D28167#629468, @kevans wrote:

In D28167#629467, @gjb wrote:

I *think* RELEASE being 12.1 (without a suffix) should be 12.1-RELEASE, since for SAs/ENs, we will likely need to append a patch number (i.e., 12.1-RELEASE.1 or something).

I do not see any concerns with the rest of the proposed change, either way.

I should revise the message to mention this, but this is accounted for in the form of what we'd typically call a port revision:

root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE -V PKG_VERSION
13.0
root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE-p1 -V PKG_VERSION
13.0_1
root@viper:/usr/src# pkg version -t 13.0 13.0_1
<

This is not how ports collection typically works, from my (user) perspective. _N only means some change to the package itself, and not to the software that was packaged. Glen' suggestion is more aligned and allows to clearly see that there was a patch on RELEASE branch vs. some (minor) fix to some packaging issue.

[kevans]

In D28167#629540, @kib wrote:

In D28167#629468, @kevans wrote:

I should revise the message to mention this, but this is accounted for in the form of what we'd typically call a port revision:

root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE -V PKG_VERSION
13.0
root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE-p1 -V PKG_VERSION
13.0_1
root@viper:/usr/src# pkg version -t 13.0 13.0_1
<

This is not how ports collection typically works, from my (user) perspective. _N only means some change to the package itself, and not to the software that was packaged. Glen' suggestion is more aligned and allows to clearly see that there was a patch on RELEASE branch vs. some (minor) fix to some packaging issue.

It could mean both if we end up backporting a fix or optimization that's worth importing without hopping forward to the version it's backported from -- that said, I have no objection to making this 13.0p1 instead to more closely match SA/EN literature since 13.0 < 13.0p1 < 13.1 still holds true, and it's still clear what it means.

[manu]

In D28167#629541, @kevans wrote:

In D28167#629540, @kib wrote:

In D28167#629468, @kevans wrote:

I should revise the message to mention this, but this is accounted for in the form of what we'd typically call a port revision:

root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE -V PKG_VERSION
13.0
root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE-p1 -V PKG_VERSION
13.0_1
root@viper:/usr/src# pkg version -t 13.0 13.0_1
<

This is not how ports collection typically works, from my (user) perspective. _N only means some change to the package itself, and not to the software that was packaged. Glen' suggestion is more aligned and allows to clearly see that there was a patch on RELEASE branch vs. some (minor) fix to some packaging issue.

It could mean both if we end up backporting a fix or optimization that's worth importing without hopping forward to the version it's backported from -- that said, I have no objection to making this 13.0p1 instead to more closely match SA/EN literature since 13.0 < 13.0p1 < 13.1 still holds true, and it's still clear what it means.

Yeah it's true that _ have a different meaning in ports so that could confuse users.
Doing pX would be better I think.

[kevans]

Map 13.0-RELEASE-p1 to 13.0p1

[kevans]

Append timestamps for ALPHA/BETA/RC packages

This is largely irrelevant for releng-produced sets because there will typically
be one build of ALPHA1 per-arch, one of ALPHA2, etc. However, for anyone else
doing continuous builds, more than one build may end up with a .a1 version and
we need to be able to distinguish subsequent builds.

Append timestamps in the form of another level of versioning:

13.0.a1.20210118195335 < 13.0.a1.20210118195348
13.0.a1.20210118195348 < 13.0.a2.20210118195348

[manu]

Thanks.