dev-cafe / branching-model Goto Github PK

The branching model defines how contributors should interact with the repository and this is basically a substantial part of the CONTRIBUTING.md file.

We don't have to do it now but as soon as things converge. Could be nicer to expose a website instead of a readme.

I recommend CC-BY-SA-4.0 but no strong opinion.

Perhaps split into two images. I will probably have a go at it.

Hello there!

How is the spec of this branching model progressing? It's a very good insight into working with a semver based project, and I'm close to implementing it in our company.

With it still being an alpha, and last changes were 11 months ago (at the time of writing this issue), I would like to know if you have plans to continue developing the model, or plans for when v1.0.0 will be released properly?

Thanks.

Motivation for release-X.Y.Z would be more consistency with https://readthedocs.org which automatically changes release/X.Y.Z to release-X.Y.Z.

Document how the tagging/minting process works on one example.

The explanation for the second branching model has just been copy-pasted from that for the first model.

First of all, I wanted to say thanks for providing a great explanation of how to effectively leverage Git tags and branches in order to support workflows for releasing semantically versioned artifacts. I'm currently working to define the release process for a project I'm working on and found this extremely useful.

I wanted to discuss the Bugfixes section in a bit more detail. In particular, you mention that bugfixes in a patch release can be ported to the branches for minor and major releases by merging upwards. You also describe how bugfixes in master can, if necessary, be ported to the branches for minor and patch releases by cherry picking downwards.

What are your recommendations for porting bugfixes not upwards or downwards, but across branches? Let's say, for example, that I've released v1.0.0, but am still working toward v1.1.0 when an issue is noticed with the former. In this situation, it makes sense to branch from v1.0.0, fix the issue, and merge the branch back into release/1.Y because v1.1.0 has not yet been released. What if it has been released and is also affected by the issue? Given that minor versions shouldn't introduce backward incompatible changes, should the release/1.0.z branch be merged into the release/1.1.z branch or should the issue be fixed directly in release/1.1.z without providing a fix in release/1.0.z?

In the same light, what if v2.0.0 has already been released and is also affected by the issue? I assume in this case that the merge into release/2.0.z is necessary given that users may have a more difficult time adopting the new major version. Does that make sense?

I hope creating an issue for this discussion is okay. If not, feel free to close it and let me know what I should do instead. Thanks!