Moya development/release flow.

[sunshinejr]

Hey guys! So lately for versions 9 and 10 we were using a branch called 9.0.0-dev or 10.0.0-dev - it was great. I was thinking if we could just remove the version name in the branch and stay with development. Additionally, everything that isn't released to the public yet, would stay on this branch. Master would have only production ready code.

Moya's flow could look like:

1. Merge everything to develop that is not a documentation change for current version of Moya (we could also just merge everything to develop and then to master)
2. When there is a need for new patch/minor version before the major one, pick commits for master and then rebase our development.
3. When we want to release a major version, and development contains only changes for this next version, just merge everything into master and rebase/reset development.
4. When we want to release a major version, but development contains also changes for versions after this one, just proceed the same as for patch/minor version.

This is only an idea, I'd love to hear your feedback on that matter. Cheers! 🍻

cc @Moya/contributors

[BasThomas]

I don't really see a reason not to work on master. I think not working on master only coplicates things, but doesn't really add any value. As we are doing releases anyway, I feel like using a separate branch doesn't do more than keeping the (updated) documentation for that change in a separate branch.

Writing this, I'd maybe even suggest putting just the documentation changes in a separate branch and merge that in once we release a new version.

[SD10]

The downside of not putting patches on master is they're not available until we make another release. I'd be fine with this workflow, I'm in the process of trying to adopt something similar on a project of my own.

I do have questions about point 2 though: How easy is it to pick commits for master off the development branch?

[BasThomas]

The downside of not putting patches on master is they're not available until we make another release.

What do you mean by that @SD10?

[SD10]

Sorry, my replies to issues when first waking up can be pretty terrible I'm realizing 😅

@BasThomas If someone installs the latest Moya from master then they get all these bugfixes/internal enhancements out of the box. If the fix is on some separate branch, they're not available until we make a new release. They could point to the development branch but it wouldn't be stable like master is.

[sunshinejr]

Having everything on master might be a problem in case we want to release a fix before we release a new major version. Let's say we add new breaking feature and then we figure out that 10.0 contains a really bad bug, we would need to do some git voodoo to make a fix release.

Thus, I suggest that we could follow git-flow, making hot fixes on master and develop, but features on develop. Opinions? @SD10 @BasThomas

[SD10]

@sunshinejr Yes this sounds like the ideal approach IMO 👍

[BasThomas]

We don’t have to do any git voodoo as we have tags/releases for every new version. That means we can just create a branch from said release, fix and merge back into master.

Or, we can use a release branch and have that reflect the latest release, making it so we don’t need to create said branch from the tag if a hotfix is needed.

All in all, it seems like a development branch is “overkill” and imo it would make sense to reflect work being done on the master branch.

_{Sent with GitHawk}

[pedrovereza]

It's still not clear to me what are the problems we're trying to fix and how a new branch strategy would help, which leads me to agree with @BasThomas.

Having everything on master might be a problem in case we want to release a fix before we release a new major version.

I think the problem here will be the same regardless of the branch strategy: apply the fix on two branches. Either on master and development, or master and branch-created-from-release-tag. It's worth noting that we don't have to release things from master, we can use any branch.

Let's say we add new breaking feature and then we figure out that 10.0 contains a really bad bug, we would need to do some git voodoo to make a fix release.

Considering the scenario where we have master and development, and one of them already has whatever was release on 10.0, that seems easier indeed. But what if we need to patch 9.0? I think we would fall back to creating a branch from a tag.

Anyway, I think we need to better describe the problems we're trying to fix in order to get to a good solution.

[SD10]

This is becoming a difficult discussion. I think what I have in mind is simple but may be naive:

• master <- documentation, bug fixes, non API breaking changes
  (this could technically include features that are: tested, non-api breaking, additive)

• develop <- anything that breaks the API, requires a major version

[freak4pc]

Just chiming in - I'm not entirely sure of the use case for splitting to develop and master. From my experience it makes thing relatively harder to maintain. Is there a specific problem we already ran to that we're trying to solve, or is this just a precaution ?

[orta]

This is quite similar to what we're thinking of doing at Artsy https://github.com/artsy/eigen/issues/2444 (master is always deployable, dev is allowed to be unstable )

[colinta]

I agree with the master is deployable and develop (or next or release, name is not very important) is where the next version is worked on. On any project, this setup makes it easy for people who are new to the code base to offer a PR that is a "quick fix". Then master is merged into develop (not rebased and I hope everyone already understands why) and work is continued. So easy!

The alternative - creating a new "bug fix release branch" - is also easy for an existing contributor, but more unintuitive for a new person arriving to the code base.

[ashfurrow]

Agree with @colinta. I personally favour the master/develop strategy, but regardless of the decision made here I would encourage us to document how we want to work, and the rationale for it. I'm happy to help/proofread any of this, just @ me :smiley:

[colinta]

(and to be extra clear - @SD10 nailed it with his description of master / develop. Patches do go into master, but breaking changes go into a separate branch.)

[SD10]

Another good benefit of the master / develop approach is then we don't have to change all the target branches of a pull request that didn't make it into a release. They also won't be automatically closed if we delete the version branch. (Experiencing this on my project right now) 😅

[sunshinejr]

Cool! Seems like we have an agreement. Would someone be up for documenting it? 😉

[colinta]

I'm happy to take a stab at it. Seems like Contributing.md is the right place for this. @SD10 and @ashfurrow I'll hit you up with a draft, and then open a PR for discussion.

[colinta]

Sorry for the delay, but here's a first draft:

https://github.com/colinta/Moya/blob/cg/branches/Contributing.md#bug-fixes-and-release-cycles

diff: https://github.com/colinta/Moya/commit/149b68bb2dc4b3fc17fa4bd2007b319f3d75cdb7

[ashfurrow]

No need to apologize – you are volunteering your time for the community, and we all appreciate it.