[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Re: Upgrade to PHP 7 - String class name and Router issue



We started with one repo then a decision was made that instead of having more organized releases and a single management structure that each package should have a life of its own and in many ways the concept of an "organized" release was abandoned in favor of just creating a new tag when there are a few new commits in the repo.  For a continuous integration type environment that's not a bad approach.  And if you aren't maintaining a large library of components/packages/libraries/whatever I feel like it would work there too.  But 43 repositories mainly managed by two or three people at best?  That definitely makes resource management much more complex.

On Mon, Feb 20, 2017 at 2:54 PM, piotr_cz <pkonieczny AT hotmail.com> wrote:
I see. Maybe that's why Laravel framework is in one repo.

On Monday, February 20, 2017 at 1:25:33 PM UTC+1, Michael Babker wrote:
Easier management of the collective resource honestly is the main one.  Easier testing of interdependencies between packages (it's all in one spot and is therefore all tested together).  My entire day yesterday was spent working through each repository on my local checkout three full times (and was starting a fourth) to update all of the test suites for PHPUnit 6.0 compatibility, enabling a testing pass on the PHP master branch (nightly builds), merging all master branch activity into 2.0 branches (and dealing with the various merge conflicts that are coming from that), and working through each package to bump the version constraints to allow 1.x or 2.x installations where practical.  It is not a quick process when dealing with over 40 repositories.

You can still have it all in one repo with the ability to pull in the individual libraries (git subsplit and similar tools exist for that, see how Symfony does it).

On Mon, Feb 20, 2017 at 4:46 AM, piotr_cz <pkoni... AT hotmail.com> wrote:
What are the pros of having one framework repo instead of multiple libraries?
IMHO Joomla framework as a whole is not great, but some libraries are and so I'm pulling these into existing project.

On Tuesday, February 7, 2017 at 5:39:58 PM UTC+1, Michael Babker wrote:
At this point I don't think it's possible without screwing up the existing repositories.  Apparently there are ways where you can recombine git repositories while retaining history, but if we tried to start doing subsplits again into those repositories (this is how you can install the individual components of Symfony versus dragging the whole framework repo in) it would damage the git tags and Composer integrations pretty badly I fear.

I don't see it happening without abandoning the currently dead https://github.com/joomla/joomla-framework repo, the entire https://github.com/joomla-framework organization, all of the existing packages through Packagist, and establishing new architecture with new names that don't collide.  Not worth it to me personally.

On Tue, Feb 7, 2017 at 10:30 AM, Walt Sorensen aka photodude <wa... AT waltsorensen.com> wrote:


On Monday, February 6, 2017 at 2:34:41 PM UTC-7, Michael Babker wrote:

Likewise, a (looking back now terrible) decision was made to not manage the Framework as a monolithic stack but as a semi-independent set of libraries.  As such, the only `joomla/joomla-framework` packages are from December 2013 and February 2014.  All updates since then rely on the individual library repositories.


Michael, how do we get back to managing the Framework as a monolithic stack and not as the semi-independent set of libraries? other than simplifying management, Is there any other benefit to going back to a monolithic stack?

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-framework.