Paths

Table of Contentst

RC phases
ClosedPublic
Actions

Authored by kevans on Jan 14 2021, 7:05 PM.

Details

Reviewers

gjb
manu

Group Reviewers

releng
pkgbase

Commits

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

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

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 36324
Build 33213: arc lint + arc unit

Event Timeline

kevans created this revision.Jan 14 2021, 7:05 PM

Herald added subscribers: emaste, imp. · View Herald TranscriptJan 14 2021, 7:05 PM

kevans requested review of this revision.Jan 14 2021, 7:05 PM

kevans added a parent revision: D28166: pkgbase: collapse -PRERELEASE into STABLE/CURRENT case for version suffix.

Harbormaster completed remote builds in B36210: Diff 82283.Jan 14 2021, 7:05 PM

(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

manu accepted this revision.Jan 14 2021, 8:13 PM

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.

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.

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.

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

Map 13.0-RELEASE-p1 to 13.0p1

Harbormaster completed remote builds in B36303: Diff 82438.Jan 17 2021, 8:11 PM

kevans edited the summary of this revision. (Show Details)Jan 17 2021, 8:12 PM

manu accepted this revision.Jan 17 2021, 8:57 PM

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

kevans edited the summary of this revision. (Show Details)Jan 18 2021, 7:55 PM

Harbormaster completed remote builds in B36324: Diff 82498.Jan 18 2021, 7:56 PM

Thanks.

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

gjb accepted this revision.Jan 18 2021, 8:09 PM

Closed by commit rG613fe5321f6c: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases (authored by manu, committed by kevans). · Explain WhyJan 19 2021, 4:26 AM

This revision was automatically updated to reflect the committed changes.

kevans added a commit: rG613fe5321f6c: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases.