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

From David G. Johnston
Subject Re: New version numbering practices
Date
Msg-id CAKFQuwbQ1PgDUtfHrUPZw0Xu_BNe3DvmK6=pLfGPZR5fkhWR9g@mail.gmail.com
Whole thread Raw
In response to Re: New version numbering practices  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Wed, Aug 3, 2016 at 12:51 PM, Greg Stark <stark@mit.edu> wrote:
On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I thought we'd pretty much done that cleanup during the cvs->git
> conversion?

I guess I'm talking about tags. I'm not clear on the distinction
between tags and branches names in git.

​Ignoring git for a moment our setup is that each major version (9.6) gets a branch when it is finally released.  For each minor release the last commit on each branch that is included in the release is tagged with both the branch/major-version AND the patch/minor-version.

I'm sure the internet can provide a better overview of the differences, within git, between tags and branches.  One way to look at it, though is that tags are
 explicit labels pointing to commits
​ whereas b
ranches are
​ implicit​ labels.

When you do:  git checkout branch you are asking for whatever HEAD - for that branch - points to.  Committing to a branch causes a new commit to be created and then HEAD - for that branch - to be moved.  So you are, by default, dealing with the implicit HEAD label within the branch "namespace".

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New version numbering practices
Next
From: Craig Ringer
Date:
Subject: Re: Detecting skipped data from logical slots (data silently skipped)