Page MenuHomeFreeBSD

Enhance the PKG_VERSION versioning sheme.
Needs ReviewPublic

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 OK
Unit
No Unit Test Coverage
Build Status
Buildable 6459
Build 6689: 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)
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.
mat added subscribers: bapt, bdrewery.
mat updated this revision to Diff 23403.Dec 29 2016, 2:11 PM

Fix typo.

matthew edited edge metadata.Dec 29 2016, 2:52 PM

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.

mat added a comment.Dec 29 2016, 3:35 PM

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... :-)

gjb edited edge metadata.Dec 29 2016, 4:26 PM
gjb added a subscriber: brd.

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.

mat added a comment.Dec 29 2016, 4:56 PM
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
mat added a comment.Jan 14 2019, 9:37 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
>
bapt added a reviewer: manu.Jun 20 2019, 2:20 PM
mat edited the summary of this revision. (Show Details)Jun 20 2019, 2:38 PM