Enhance the PKG_VERSION versioning sheme.
Needs ReviewPublic
Actions

Authored by mat on Dec 28 2016, 3:37 PM.

Details

Reviewers

gjb
matthew
manu

Summary

This is so that it fits better with how pkg version works.

What we have now is:

          head
11.sYYYYMMDD +
             |
             |
             |
     11.0.aX |
             |        stable/11
             +----------------+
12.sYYYYMMDD |        11.0.bX |
             |                |
             |                |
             |                |
             |                | releng/11.0
             |                +---------+
             | 11.0.pYYYYMMDD | 11.0.rX |
             |                |         |
             |                |    11.0 |
             |  11.0sYYYYMMDD |         |
             |                |  11.0_X |
             |                |         |
             |                |         |
             |                |         v
             |                |
             |        11.1.bX |
             |                |
             |                | releng/11.1
             |                +---------+
             | 11.1.pYYYYMMDD | 11.1.rX |
             |                |         |
             |                |    11.1 |
             |  11.1sYYYYMMDD |         |
             |                |  11.1_X |
             |                |         |
             |                |         |
             |                |         v
             |                v
             v

On the head branch, we have:

11.sYYYYMMDD < 11.0.aX
11.0.ax < 12.sYYYYMMDD

On the stable branch, we have:

11.0.aX < 11.0.bX
11.0.bX < 11.0.pYYYYMMDD
11.0.pYYYYMMDD < 11.0sYYYYMMDD
11.0sYYYYMMDD < 11.1.bX

...

On the releng branch, we have:

11.0.bX < 11.0.rX
11.0.rX < 11.0
11.0 < 11.0_X

We also have 11.0(_X) < 11.0sYYYYMMDD so the release branch is before
the stable branch.

Diff Detail

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 6422
Build 6655: arc lint + arc unit

Event Timeline

mat updated this revision to Diff 23332.Dec 28 2016, 3:37 PM

mat retitled this revision from to Enhance the PKG_VERSION versioning sheme..

mat updated this object.

mat edited the test plan for this revision. (Show Details)

Herald added a subscriber: emaste. · View Herald TranscriptDec 28 2016, 3:37 PM

mat added a reviewer: releng.Dec 28 2016, 3:38 PM

mat edited reviewers, added: gjb, matthew; removed: releng.Dec 29 2016, 2:11 PM

mat set the repository for this revision to rS FreeBSD src repository - subversion.

mat added subscribers: bapt, bdrewery.

Fix typo.

Why 11.0_1 for RELEASE patchlevels? Why not 11.0.1? Given that Major.Minor.Patch is a pretty well established
convention for a huge number of software projects.

So the sequence for a release is something like this:

% pkg version -t 11.0.99 11.1.a1
<
% pkg version -t 11.1.a1 11.1.b1
<
% pkg version -t 11.1.b1 11.1.r1
<
% pkg version -t 11.1.r1 11.1
<
% pkg version -t 11.1 11.1.1
<

And for comparing RELEASE vs STABLE:

% pkg version -t 11.1 11.1s20161229
<
% pkg version -t 11.1.1 11.1s20161229
<

although I don't really see how comparing RELEASE and STABLE versions like that makes any sense.

IIRC, the existing 10.3-RELEASE-p99 numbering originated sometime after the 5.2-RELEASE era because we had
things like 5.2.1-RELEASE back then -- but IIRC that 3-part version for the release branch hasn't been used
in that way since. Now we've got -RELEASE branches, we tend to solve problems in releases by issuing Errata Notices or Security Advisories.

In D8943#185417, @matthew wrote:

Why 11.0_1 for RELEASE patchlevels? Why not 11.0.1? Given that Major.Minor.Patch is a pretty well established
convention for a huge number of software projects.

Because it was like that before, it is the one thing I did not change :-)

If we want, to stick with our numbering, we could do 11.0p1 which would work too.

although I don't really see how comparing RELEASE and STABLE versions like that makes any sense.

Well, STABLE is supposed to be after RELEASE, so... :-)

Please don't commit this just yet. Brad Davis and I were discussing the PKG_VERSION topic over the past week or so, so I've added him as a subscriber. I'd like to think more about this, specifically how it relates to -RELEASE versions and numbering/patch-level versioning there.

In D8943#185468, @gjb wrote:

Please don't commit this just yet. Brad Davis and I were discussing the PKG_VERSION topic over the past week or so, so I've added him as a subscriber. I'd like to think more about this, specifically how it relates to -RELEASE versions and numbering/patch-level versioning there.

I don't plan on committing this, I'm just a ports committer :-)
But as the current scheme was crappy, I wanted to give it a shot.

mat edited the summary of this revision. (Show Details)Aug 4 2017, 11:05 AM

ping this ?

gjb added inline comments.Jan 15 2019, 3:13 PM

Makefile.inc1
342	Shouldn't this be '.s${_TIMENOW}' ?

mat added inline comments.Mar 18 2019, 10:46 AM

Makefile.inc1
342	No, unless mistaken, between 12.0 and 12.1, stable/12's REVISION will contain 12.0, and: $ pkg version -t 12.0 12.0.s20190318 > $ pkg version -t 12.0 12.0s20190318 < $ pkg version -t 12.1 12.0s20190318 >