Sounds good. So: RC tags are named like 4.1.0RC1, 4.1.0RC2, etc. release tags are named like rel/4.1.0 branches are named like branch-4.1, branch-4.1.1, etc.
cheers, Colin On Wed, Jan 27, 2016 at 10:45 AM, Sean Busbey <[email protected]> wrote: > nope, the rel/ prefix is reserved for things that have been approved by a > PMC. RCs that require a tag should still stay in normal tags. > > On Wed, Jan 27, 2016 at 12:43 PM, Colin P. McCabe <[email protected]> > wrote: > >> Thanks, Sean. That sounds like a good idea. I guess we can drop the >> "-release" suffix then. "rel/4.0" and "rel/4.0.1", etc. seem pretty >> self-explanatory. My main goal was just to make branches look >> different than tags. I would prefer to keep the "-branch" suffix on >> branches just to make that clear as well. >> >> Sean, would RCs also receive the "rel/" prefix, or not? I'm guessing >> not, since we don't need to preserve them forever. >> >> best, >> Colin >> >> >> On Tue, Jan 26, 2016 at 9:26 PM, Sean Busbey <[email protected]> wrote: >> > with the new ASF release tag policy, this would make our release tags >> look >> > like 'rel/4.0-release' and 'rel/4.0.1-release'. >> > >> > the 'rel' prefix makes the distinction between branches and tagged >> releases >> > clear to me. what do others think? >> > >> > On Tue, Jan 26, 2016 at 10:41 PM, Masatake Iwasaki < >> > [email protected]> wrote: >> > >> >> Sorry for late reply. >> >> >> >> I agree with the proposed naming conversion for branches and tags. >> >> If there is no objection further, we should close HTRACE-331 and >> >> prepare for the next release. >> >> >> >> Thanks, >> >> Masatake Iwasaki >> >> >> >> >> >> On 12/15/15 04:53, Colin P. McCabe wrote: >> >> >> >>> As part of our release process, we create git tags for each release >> >>> candidate (RC)... for example, 3.1.0RC9 and 4.0.1RC1. We also often >> >>> use release branches-- for example, the "4.0" branch. >> >>> >> >>> As Sean Busbey pointed out, we should also be creating "release" tags, >> >>> so that people who want to check out the release can do so without >> >>> having to figure out which RC was anointed as the release. I also >> >>> think we should adopt a naming convention for release branches and >> >>> tags so that people attempting to check out tags don't accidentally >> >>> check out branches, and vice versa. >> >>> >> >>> The branch and tag naming is confusing right now. For example, >> >>> someone running "git checkout 4.0" might be surprised to learn that >> >>> this checks out a branch currently containing 4.0.1, not the git tag >> >>> for the 4.0 release. >> >>> >> >>> I'm thinking we should adopt the following convention: >> >>> * release tags should have "release" in the name. So the tag for >> >>> htrace 4.1 should be "4.1-release" >> >>> * RC tags continue to be "4.1-RC1" and so forth. >> >>> * release branches should have "branch" in the name. So the branch for >> >>> 4.1 should be "branch-4.1". In general, branches should not include >> >>> "RC[0-9]" or "release" in the names, to avoid confusion with the tags. >> >>> >> >>> Let me know what you think. If you guys agree, I will also create >> >>> 4.0-release and 4.0.1-release tags corresponding to those releases. >> >>> >> >>> best, >> >>> Colin >> >>> >> >> >> >> >> > >> > >> > -- >> > Sean >> > > > > -- > Sean
