Meta framework package

[ghost]

Updates Joomla Framework from a Composer Library to a Composer Metapackage

Will need version information added when it is time to release

Does not include phpcs as requirements for phpcs need correcting

[dongilbert]

I think the idea is a good one here, although I wouldn't want to keep around the old history as such, since we're doing away with all the code. (A git clone pulling in all the history takes a long time). IMO the better approach would be to create a new repo at joomla-framework/starter or something like that that does what you're doing here, and have different base "distros" to work with. So you can have the full joomla experience with every package we offer downloaded, or you can download an app starter kit, etc.

For this repo - we want to archive it like we did with the Platform repo.

[piotr-cz]

What about adding the .gitmodules, so we will able to track Pull requests to all packages in one repository (ie. joomla-framework/starter)

[submodule "src/application"]
    path = src/application
    url = git://github.com/joomla-framework/Application

[ghost]

Composer doesn't clone metapackage's, so there is no concern about placing it in this repository. Composer only checks the composer.json file for the meta package to find all the packages it contains[which it can do with a targeted single file checkout]

I would suggest placing it here and then you can always split off a new meta if you want. The main issue is that the current packagist package points here - and you can't just point it someplace new since that breaks backwards compatibility[ie anyone who is currently using the entire framework from the ver1 package]. Adding this to master won't break b/c because anyone using the ver1 package will continue to use it - while anyone who wants to use the latest can use dev-master.

At the very least, if you can create a new branch[call it meta] and merge this pull request in THERE, that can solve half the problems. Then it is easy to specify a version of "dev-meta" and it will grab the latest code in the meta branch.

The second half of this migration is to update the package version info - but because of the way Composer handles overriding repositories, I can't really test the version info to find the right combo until a there is a branch in this repository with this pull request.

Once that is all complete, then if you really don't want this history data, you can copy the meta framework code to a new repo[I'd sugest joomla-framework/metapackage to be explicit.

[dongilbert]

Changing it in packaging and GitHub is trivial, as it auto redirects to the new location.

Sent from my iPhone

On Mar 14, 2014, at 5:31 PM, Gary A Mort [email protected] wrote:

Composer doesn't clone metapackage's, so there is no concern about placing it in this repository. Composer only checks the composer.json file for the meta package to find all the packages it contains[which it can do with a targeted single file checkout]

I would suggest placing it here and then you can always split off a new meta if you want. The main issue is that the current packagist package points here - and you can't just point it someplace new since that breaks backwards compatibility[ie anyone who is currently using the entire framework from the ver1 package]. Adding this to master won't break b/c because anyone using the ver1 package will continue to use it - while anyone who wants to use the latest can use dev-master.

At the very least, if you can create a new branch[call it meta] and merge this pull request in THERE, that can solve half the problems. Then it is easy to specify a version of "dev-meta" and it will grab the latest code in the meta branch.

The second half of this migration is to update the package version info - but because of the way Composer handles overriding repositories, I can't really test the version info to find the right combo until a there is a branch in this repository with this pull request.

Once that is all complete, then if you really don't want this history data, you can copy the meta framework code to a new repo[I'd sugest joomla-framework/metapackage to be explicit.

— Reply to this email directly or view it on GitHub.

[ghost]

You will need some special configs to change it in packaging.

"joomla/framework" : "1.0" has to point to a repository containing all the packages as was configured in this repository along with the v1.0 tag[so composer installs the entire framework as one package]

"Joomla/framework": "dev-master" should point to a repository where the master branch contains a meta package which installs the latest dev code for each and every joomla package[as per this patch request]

"Joomla/framework": "1.1" should point to a repository where there is a tagged release in one of the branches which contains the same meta-package info as here, but instead of using @dev for the version info, the package versions should all be set to 1.1

"Joomla/framework": "1+" has to be able to get all of the above from a single repository, at which point it would either select "dev-master" or "1.1" depending on the composer configuration.

It doesn't really matter if you point the package to a new repository or not, whatever repository you use must include both the 1.0 joomla framework structure with a v1.0 tag AND the meta package for future versions.

If you can figure out a way to do that with a split repo, more power to you. But considering that as of now the framework repos have changed in a way which was inadvertently not backwards compatible - it ought to be fixed.