Re: New version numbering practices - Mailing list pgsql-hackers

From Greg Stark
Subject Re: New version numbering practices
Date
Msg-id CAM-w4HNAM06_HRioO01L6kZWMnmwXWcZktkZ5+jXw7sqwsv85g@mail.gmail.com
Whole thread Raw
In response to Re: New version numbering practices  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New version numbering practices  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 3, 2016 at 5:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, the rule would be that "REL_xx" is a branch, "REL_xx_yy" is a
> release tag.  Neither of these is confusable with old-style
> branch or tag names.  The alternative seems to be saying that
> "REL_xx_STABLE" is a branch while "REL_xx_yy" is a release tag.
> That works but it doesn't seem to have all that much to recommend it;
> unless there is code in the buildfarm or elsewhere that really wants
> to see _STABLE in the branch names.

It would also be nice to have a tag or branch name for the development
branch. Right now git-describe --tags on a random revision between 9.4
and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or
something like REL9_5_BETA2-33-g55a2cc8 if it happens to be after a
beta. It's really hard to tell what release the revision you're on is
actually between from that.

There's also a git feature I just noticed called "annotations". Tags
can be "annotated" with a commit message and then git describe will
only use those and skip other tags that are not annotated. Currently
we appear to have no annotated tags. (which confuses me because there
are clearly commit messages for the tags with logs like "Stamp
9.5alpha" c.f. f78329d594c2fe893f9174d5b3da7d3fbc6dd8b6)

It would be nice if git describe on a random revision between 9.4 and
9.5 always printed something like REL_09_05_DEV-* which indicated it
was some revision committed after 9.4 was branched and before 9.5.0
was released. (That would sort incorrectly so maybe some further tweak
is needed?)

-- 
greg



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: New version numbering practices
Next
From: Tom Lane
Date:
Subject: Re: New version numbering practices