RFC: Formalize a branching strategy

[ashfurrow]

Today, most Eigen development is done on the master branch, but that makes it difficult to release patch releases based on the last stable branch. For example, master currently can't be shipped because it has incomplete Messaging work.

I propose we move to a git flow which boils down to:

• Master branch is always stable/deployable
• A develop branch is made off of master
• Feature branches (like messaging) are PR'd into the develop branch
• When releasing, master is updated with the develop branch

There are provision for patch releases, too.

We can do whatever we want, but this process is pretty established/popular/well-understood. In any case, we should decide on what to do and document it.

/cc @artsy/mobile

[sarahscott]

I think this would be great!

[sarahscott]

@alloy @orta thoughts?

Running into this again because I want to solve this fonts issue for the next release or beta ( #2441 ) and I'm probably going to have to merge the fix into 2 different branches because it's relevant for master as well.

[alloy]

Oh I gave it a 👍 on the original message from @ashfurrow.

[ashfurrow]

I'm bringing this up again because we have shipped 4.0 and it's time to have a discussion about branching in Eigen. dB brought up something in this morning's Sprint Kickoff: he reiterated that master should always be deployable (like on our web projects). We don't, and haven't, adhered to that principle on Eigen and I believe we should start as soon as possible.

I don't know what a specific branching strategy looks like – maybe a protected develop branch that's the target of most PRs – but we need something. #2500 was merged into master, which is now no longer in a deployable state, for example.

[orta]

Add a peril check to encourage people to ship to a develop branch by default, unless it's classed as a release?

[ashfurrow]

Oooooh I like that idea.

[pvinis]

I guess this can be closed now? I feel our git ways on the app are working well.
(I was just looking around for RFCs in eigen and saw this open still 😅)

[ashfurrow]

Agreed.

For posterity, the solution we went with:

• master is always deployable.
• Features that take longer than a sprint are placed behind a feature flag (see docs).
• Features get QA'd every two weeks for our springily submission to App Store review.

Extra branches? Extra work 🙅‍♂️

The QA process for really large features is still evolving – MX and Galleries are meeting this week to discuss this for viewing rooms specifically, and I imagine we will generalize out from there (and document our decision).

[MounirDhahri]

this can go to our work agreements

Agreed.

For posterity, the solution we went with:

• master is always deployable.
• Features that take longer than a sprint are placed behind a feature flag (see docs).
• Features get QA'd every two weeks for our springily submission to App Store review.

Extra branches? Extra work 🙅‍♂️

The QA process for really large features is still evolving – MX and Galleries are meeting this week to discuss this for viewing rooms specifically, and I imagine we will generalize out from there (and document our decision).