OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Proposed Simplification of GitHub Repository Branching Strategy

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

My proposal is to eliminate the release branch in favor of only using GitHub "Releases".

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.


David Lemire

Systems Engineer

HII Mission Driven Innovated Solutions (HII-MDIS)

Technical Solutions Division


302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301575-5190 | Mobile (443) 535-1182

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]