Page MenuHomeFreeBSD

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

Authored by kevans on Jan 14 2021, 7:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 7, 11:21 AM
Unknown Object (File)
Thu, Mar 7, 11:21 AM
Unknown Object (File)
Thu, Mar 7, 10:21 AM
Unknown Object (File)
Dec 20 2023, 5:06 PM
Unknown Object (File)
Dec 20 2023, 4:55 AM
Unknown Object (File)
Sep 5 2023, 5:31 AM
Unknown Object (File)
Sep 5 2023, 5:31 AM
Unknown Object (File)
Aug 31 2023, 12:58 AM
Subscribers

Details

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)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

(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")

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.

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
<

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

This revision is now accepted and ready to land.Jan 14 2021, 8:08 PM
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.

In D28167#629540, @kib 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 requested changes to this revision.Jan 17 2021, 4:08 PM
In D28167#629540, @kib 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.

This revision now requires changes to proceed.Jan 17 2021, 4:08 PM

Map 13.0-RELEASE-p1 to 13.0p1

This revision is now accepted and ready to land.Jan 17 2021, 8:57 PM

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

This revision now requires review to proceed.Jan 18 2021, 7:54 PM
This revision is now accepted and ready to land.Jan 18 2021, 8:05 PM