0

We're developing a mini-POC framework as a project for a course at our university.

The repository is available here

We're following a laravel directory structure:

  1. The main framework logic is in the liteframework folder
  2. The main user added logic is in the app folder.

Any user can clone the framework and start developing the application. This makes it hard to have two nicely organized github repos, because readmes and configs will conflict (and other common, but changeable files too).

The main idea is to use this project as a start for our application and develop some actual content based on the functionalities of the framework.

We're working in parallel on both projects the framework and the application. Sometimes, changes to the framework have to be added to the application.

Normally, a real framework would use some kind of versioning system to provide with new features, but since we don't have that, here is what we do:

  1. Create a remote source git remote add liteframework <url>
  2. When the framework gets changed we just git pull liteframework master

But the problem is we always get conflicts in some files that get changed, for example readme, or config. Also, it doesn't feel like the right way to integrate new features.

What is the best way in this scenario? How can we smoothly add new features without conflicts?

Denis Rozimovschii
  • 428
  • 1
  • 6
  • 19
  • Why don't you have versioning? Why don't you have an isolated framework repo and multiple app repos? Then you could just use pip. Note that the language is important here. – Dave Newton Jun 07 '18 at 20:20
  • We do have an isolated framework repo. Note that the link is for the framework repo, I didn't offer the link for the application – Denis Rozimovschii Jun 07 '18 at 20:20
  • Essentially, the application has exactly the same structure except for a few user defined files in the app folder, a changed config and readme files – Denis Rozimovschii Jun 07 '18 at 20:22
  • I'm confused. A framework is a library with an opinion. Whether or not the app has a similar folder structure shouldn't be relevant--you shouldn't pull the framework *in* to the app, the app should *use* the framework. – Dave Newton Jun 07 '18 at 20:23
  • I agree. As a framework, it provides a MVC architecture and ways to interact with request and give responses, as well as render views. This is what it does. But sometimes we add new functionalities to the framework and have to update the application we're developing so that the framework files contain newly added features – Denis Rozimovschii Jun 07 '18 at 20:26
  • We tried to replicate Laravel in here, in the way that the user could copy the framework repo and start working on the content and routes and controllers. What we failed to understand is how to update, when new features are being added to the original framework repo – Denis Rozimovschii Jun 07 '18 at 20:29
  • 1
    Any given app depends on a given version of the framework. When you need to update the framework, the app may need to change--that is the nature of things. Unless you provide a script/program to automagically update the app artifacts, you update the same way everybody else does--manually :) – Dave Newton Jun 07 '18 at 20:31
  • Thank you, but honestly this sounds even worse than manually resolving conflicts in the config and readmes. Maybe a better option will be to move possible conflicting files into the framework folder and make the user copy them to the root – Denis Rozimovschii Jun 07 '18 at 20:33
  • The problem with essentially cramming the framework and app together is that not only do you need to resolve framework conflicts, which isn't something a framework user should be expected to do, you *still* need to update the app to account for framework changes-essentially the worst of both worlds. – Dave Newton Jun 07 '18 at 22:14

0 Answers0