I’ve been thinking for a while about how best to integrate work done as part of MP1 with the rest of the codebase. The work being done in MP1 is fairly incompatible with the existing architecture, and we’ll have to start ripping out huge swaths of code before it’s done. If that work is merged to
master immediately when finished, we’ll have committed ourselves to finishing MP1 in its entirety (or close) before we’re able to even do a platform release.
Rather, I’m inclined to keep
master entirely focused on improvements on the current architecture only, so that releases can continue normally, and we can get improvements/bugfixes into production in parallel.
I’ll come up with a nice visual later, but basically I’m proposing a branch like
mp1-dev or something like that, and all PRs pertaining to MP1 will be merged there. While
master chugs along the current way, I’ll take care of ensuring commits are merged back up into
mp1-dev so that it has the relevant fixes as well, helping to prevent merge conflicts at the end of MP1.
Eventually, when we’re ready, we’ll merge
mp1-dev back into
master. This will be a very significant set of changes that will be landing on
master at this point, so we’ll want to make sure we’re ready to make the mental switch to the new architecture, and drive towards a new release. That new release may very well be 1.0.
All that said, we will want to keep activity in
master limited to only a bare minimum - things that really need to be improved or fixed before MP1 is done. Even though we’re allowing that kind of work to continue, it really doesn’t make a lot of sense to think about giant improvements or big undertakings until MP1 is in place.