[Idea] Maintain and publish mobx 4 & 5 from the same branch

[Bnaya]

I can't say i know mobx codebase very well,
But as what i've seen most of the code of 4 & 5 is very similar,
The difference is mostly the proxy part.

What if struct the code in a way that only the different parts will be behind a build flag (or even runtime flat if the developer wishes)
And keep all of the code on master.
Another idea, that i'm not sure if will work:
Use monorepo, one package will be 4.x and the other 5.x, and the shared code will be in a shared package (That won't be published, but will be bundled)

Kinda related #1957

[danielkcz]

Monorepos are the pain, mainly because there are no solid tools to work with them (Lerna is crap).

Merging codebase does sound appealing, but I can imagine it would make code fairly messy even with build flags. Not sure really. If you are willing to give it a try, it could be really interesting and easing the maintenance pain toward the future.

However, it would mean to release V6 and motivate people to upgrade. We can hardly just deprecate V4 as it's considered LTS. New bugs would still need to be fixed in V4 branch.

[Bnaya]

The initial idea is to keep publish V4 & V5,
just from the same branch (with separate package.json, or writing the version on the fly before publish),
And build/bundle flags will produce the correct bundle before each publish.
I believe i will find time to POC it after #2079 will get finalized

[mweststrate]

Separate subpackages in the same branch sounds fine to me, if it isn't confusing for new contributors. Mixing code bases is a real pain. I tried, so I can confirm that it at least is not easy :).

[Bnaya]

My personal experience from my last PR, even a small PR to both of the branches was confusing.

Have you tried that with mobx or other projects?

[danielkcz]

Separate subpackages in the same branch sounds fine to me, if it isn't confusing for new contributors.

I can imagine it could be confusing for reviews to basically see changes two times in there.

Mixing code bases is a real pain. I tried, so I can confirm that it at least is not easy :).

Not easy but also not impossible I assume? I kinda agree it would be the best way if it can work out somehow.

[mweststrate]

mobx-state-tree packages multiple projects in the same repo. Works pretty smooth (I'm generally in favor of mono repo's and single branches of work, as it makes coordination so much easier, so I do think it is a good idea :))

…

On Wed, Oct 2, 2019 at 12:25 PM Bnaya Peretz ***@***.***> wrote: My personal experience from my last PR, even a small PR to both of the branches was confusing. Have you tried that with mobx or other projects? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2120?email_source=notifications&email_token=AAN4NBCDKPC24C723ROTWILQMSAMFA5CNFSM4IY74CH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAENHRQ#issuecomment-537449414>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN4NBELFJOCRYTGLEO3TADQMSAMFANCNFSM4IY74CHQ> .

[mweststrate]

I can imagine it could be confusing for reviews to basically see changes

two times in there. Agreed, but I think in the PR template we can signal that the change initially should only be made to the mobx5 one, until approved, and then backporting can be done (in same PR), but that reduces burden for both reviewer and submitter, as that last part can be glanced over. With the docs in there as well, this is gonna be a much much better setup to land new things onto :)

…

On Wed, Oct 2, 2019 at 12:29 PM Daniel K. ***@***.***> wrote: Separate subpackages in the same branch sounds fine to me, if it isn't confusing for new contributors. I can imagine it could be confusing for reviews to basically see changes two times in there. Mixing code bases is a real pain. I tried, so I can confirm that it at least is not easy :). Not easy but also not impossible I assume? I kinda agree it would be the best way if it can work out somehow. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2120?email_source=notifications&email_token=AAN4NBGW235FCYS2XNNUH3DQMSAZ5A5CNFSM4IY74CH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAENPVA#issuecomment-537450452>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN4NBB4IYMIT6GUJMXB7ZTQMSAZ5ANCNFSM4IY74CHQ> .

[danielkcz]

I really don't have much (almost none) insight into the repo code base, but perhaps we could go a middle way and besides folders for V4 and V5, there could be a common one for code that is the same across those versions. Perhaps even restructure it to reuse as much as possible.

Personally, I am totally DRY guy, so any sort of copy&pasting makes me rather uneasy.

[danielkcz]

Also note, that with two different branches doing the diff is very easy. With both codebases in different folders, you cannot really do git diff, so that could make contributing somewhat harder.

[mweststrate]

@Bnaya docs are now in the master branch, so that blocker is gone :)

I originally started with trying to do MobX 4 and 5 with a largely common code base. But that got a real big untangable mess very quickly. Imho clarity and maintainability are more important than dry :).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Bnaya]

Unfortunately i can't find the time to work on it.
i will close it for now.

[mweststrate]

No problem! I'll reopen it, as I think it is a cool idea nonetheless, and I or somebody else could pick it up.

[mweststrate]

This has been done by @FredyC, so closing!