Ticket #13283 (confirmed PLIP)
Merge some plone.app.* packages into the Products.CMFPlone distribution
|Reported by:||davisagli||Owned by:||davisagli|
Description (last modified by witsch) (diff)
Proposer: David Glick
Seconder: Andi Zeidler
Plone's core currently includes 38 packages in the plone.app namespace. In many cases this separation is unnecessary and slows development of Plone core. In some cases there are good reasons for the separate packages, but we have identified 18 packages that have little benefit to being packaged separately (they are interdependent and always required in Plone) and just cause unnecessary work for the release manager. We propose merging their repositories into the Products.CMFPlone repository (including history) and always releasing these packages as part of the Products.CMFPlone distribution.
- Package namespaces must not change.
- Package history must be retained.
- There are other dependencies of CMFPlone for which we should maybe do this, but we are focusing only on the plone.app.* ones for now.
Proposal & Implementation
Repositories can be merged using the subtree merge strategy described at http://nuclearsquid.com/writings/subtree-merging-and-you/
This merges both the history of development (appearing as a separate git branch + a merge) and the distribution of the packages (i.e. they are located in the same egg).
Git submodules were considered, but would still be a pain for both the release manager and other users of the coredev buildout.
We plan to merge the following packages into Products.CMFPlone:
These plone.app packages are Archetypes-specific and not included in the proposal:
These plone.app packages are optional features and not included in the proposal:
- plone.app.form (at least, hopefully it is optional soon)
Sometimes individual packages need to be upgraded beyond the "official" version for a release of Plone in order to fix a bug. This can still be done in an emergency, by releasing the package that needs to be upgraded in its own egg, and making sure it gets positioned in sys.path to take precedence over the package in the CMFPlone egg. But this should be necessary less often, because the simplified Plone distribution will be easier to release more frequently. Also, we've chosen packages for this proposal that are fairly stable.
Completing this PLIP makes it a bit harder to port fixes between master and the maintenance branch of the packages in question. It is still possible by treating the old package as a special remote and doing a subtree merge, but it is a bit more complicated.
In some cases add-ons will declare dependencies on distributions for these packages that are no longer necessary, since the code is in the Products.CMFPlone distribution. This can be mitigated by making new empty releases of the distributions that are being deprecated, so that it is harmless if they are accidentally included.
David Glick & Andi Zeidler.
So far we have conducted some experimental merges which can be checked out using dependency-merges.cfg in 4.3 coredev.
- Status changed from new to confirmed
- Component changed from Unknown to Backend (Python)