2

I built a base/skeleton user-based web app. It just has sign up, log in, log out, forgot password, verify email address, etc. Now I can easily build user-based apps by developing on top of the base app. For example, I could build a social network or a message board.

But when I upgrade the base app how should the "child" apps get the upgrades?

The base app doesn't use a framework. But it's just some functions, classes and libraries. So one could easily edit the functions or extend the classes or whatever as a possible way to facilitate upgrades.

I've read that you can sync upstream apps when you fork them with Git. But is that alone a feasible solution?

Must I come up with some plugin system or framework in order to make this possible?

Can I keep it more fundamental and just do it through editing functions and class methods?

Improve this question

1 Answer 1

Reset to default
1

I'm afraid that there is no magical tool for that.

Keeping the fork in sync with its upstream original (e.g. on BitBucket or GitHub) is designed for syncing common shared base files and not for intelligent updating of changed source. There are many limits to this approach and it will not be able to cope with major changes in the forked code.

So the good way to make this happen, would be to design the code for extensibility, and in consequence, use to the utmost possible the open/close principle to design classes that are easily extended. The rule shall then be to never change the original code. It's more the "base" philosophy rather than the "skeleton" possibility. Another point is to define a robust API.

In this way you could always synch the original (unchanged) version of your code, the adaptations of your custmoer being in other files, overriding when necessary your original classes, and remaining preserved of unexpected base changes.

Improve this answer
2
  • I'm trying the Git upstream method. I made a copy of the repo and set an upstream remote pointing back to the original. Then I just merge upstream/master into the copy's master. So it seems no different than normal merging.
    – Ryan
    Nov 1, 2019 at 0:49
  • @Ryan exactly; this is why it is not a good idea that user just changes the code as desired: sooner or later merge conflicts will occur. Therefore, design the code so as to avoid that customer wants to change it in his fork (relying on language semantics rather that git’s text processing). This is safe, and it’s the underlying philosophy to a lot of package managers. If changes can really not be avoided in some file, then, at least isolate the changeable parts in clearly idenfified sections of your source file and provide instructions on how to solve the merge conflicts.
    – Christophe
    Nov 1, 2019 at 9:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.