On Wed, Aug 3, 2016 at 5:27 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
