master branch has the beta constitution

[lflfm]

Generally speaking, git master branches contain the "production", "stable" code and betas/patches are kept in branches to be merged when "ready"/"released".
The Holacracy constitution currently has the beta version in the master branch and segregation being done only with tags. Of course having the tags is perfect, working just like in software but anyone that's not familiar with this may/will come into GitHub and see the beta/dev version of the constitution instead of the currently official one.

So, my tension here is that one must be familiar with GitHub low a direct link to the versions or they may believe that GitHub only stores the beta version and the fact that standard use of Git Branches is not being followed. The direct impact on my role as Holacracy Practitioner is that whenever I refer to the constitution on GitHub, I must switch from master branch to tag v4.1. My proposal is that a new branch is created (maybe called "beta") to keep versions 5+ and leave only the current active version (v4.1 at this time) in the master branch.

[brianjrobertson]

Ah, thanks, this is helpful, and I really like the idea, though it'd take me enough effort to restructure this now that I doubt it'll hit the top of my priority list (given my relative inexperience with github). At the least though, I'll switch to this paradigm as soon as we have a v5.0 release, and then continue further iterating in a branch from there.

[kisg]

There are multiple ways of using Git (and Github). Many projects use the master branch for the "in-development" version of their product and create release branches and tags for stable versions. I see no problem with the Constitution following the same model:

• When 5.0 is released, a new 5.0-stable branch is created, where only bug fixes are allowed. Patch releases are done from this branch, every release is tagged.
• External references to released constitution versions should be done using the tags.
• The master branch continues with the development of the next feature update
• To make it easy for newcomers, document this process in the README.md of the master branch with links to the latest stable branch.

[brianjrobertson]

Hmm, both options seem quite workable, though I'm swayed by the argument that someone unfamiliar with github is more likely to find the mater branch when poking around, and thus the master branch is best for the most current stable release. Given everything is now done in the dev version for v5.0, it's about to become the most stable release, thus I'm closing this issue (and will use branches for future development versions).