After various discussions and some analysis, I'm proposing a simplification of the GitHub repository branching strategy currently defined in the TC' Documentation Norms. While this primarily affects work product editors, the norms and the repositories are in support of the TC's objectives, so I'm sending this to the TC mail list / Slack #general channel.
The current approach has three branches:
- published (formerly master)
- release
- working
The original intent of the three branch structure was that work product development would occur in the working branch and be checkpointed to the release branch when the editor declared a working draft (WD), using a pull request. The published branch is reserved for TC/OASIS-approved specifications and standards.
Another part of this strategy was to use the GitHub "Release" feature to package the WD, creating a ZIP file for uploading to OASIS. In short, I've realized that both having a release branch and creating release packages is redundant: a release package can be based on the working branch and it's just as easy to find by examining the repository's Release entries as by looking at the release branch.
If anyone sees a reason to retain the current three-branch strategy, please articulate it in a reply.
Dave
David Lemire
Systems Engineer
HII Mission Driven Innovated Solutions (HII-MDIS)
Technical Solutions Division
302 Sentinel Drive | Annapolis Junction, MD 20701
Work (301) 575-5190 | Mobile (443) 535-1182