plone.app.upgrade: remove old upgrade code?

[mauritsvanrees]

Currently plone.app.upgrade has code to upgrade from Plone 2.5.0 to 5.1. That is somehow nice, but is it really needed and useful?

In the upgrade docs we say: "Always upgrade from the latest version of 4.x to the latest version of 5.x (at the time of writing 4.3.7 to 5.0.2). This will resolve many migration-specific issues." In other words: first upgrade your site from version X to 4.3.latest, and then upgrade to 5.latest.

That being the case, I think it is better to remove a part of the old upgrade code from plone.app.upgrade. Two specific issues have triggered this for me:

1. PLIP PLIP: Get rid of portal_quickinstaller #1340 has landed in Plone 5.1. This deprecates the CMFQuickInstallerTool. In plone 5.1, instead of getToolByName(context, 'portal_quickinstaller') you should do from Products.CMFPlone.utils import get_installer; get_installer(context). And in Plone 6.0 we will likely not ship at all with Products.CMFQuickInstallerTool. Now the danger is that old upgrade steps that use portal_quickinstaller will get updated to use get_installer. When upgrading from Plone 2.5 directly to Plone 5.1, the get_installer function will be available, but it's anyone's guess whether a random upgrade step from say 2.5.2 to 2.5.3 that uses the quick installer will also do the expected thing when using this new get_installer thingie.
2. Issue Remove SecureMailHost #965 wants to remove Products.SecureMailHost. Since Plone 4.0 this tool is no longer needed. Its secureSend method should no longer be used. plone.app.upgrade has a function in v40/alphas.py to replace the SecureMailHost object with a standard MailHost object. For this upgrade to work, the Products.SecureMailHost package must be available. So plone.app.upgrade has this in its setup.py. So Plone 5.1 still ships with the SecureMailHost package, because plone.app.upgrade pulls it in.

Not counting an autopep8 change in the tests a few months ago, here are some numbers on when the latest change was in plone.app.upgrade code:

• v25: 3 years ago, and this was only to fix some tests in Plone 5 due to removal of css/js registries, so I wonder if this was sane to apply on an actual site. See plone/plone.app.upgrade@07ea2a9. Otherwise latest change: 6 years ago.
• v30: 4 years ago
• v31: 4 years ago
• v32: 6 years ago
• v33: 6 years ago

So there are hardly any changes in the old code.

So here is an idea. plone.app.upgrade is currently at version 1.3.27.

• For Plone 4.3 create branch 1.4.x. Actually remove the Plone 5 upgrade code from it.
• For Plone 5 use the master branch and call the version 2.x. Probably the first release that has code for Plone 5.1 alpha should be 2.1.x for good measure, as that is what we have been doing so far: for every minor Plone version we update the minor version of plone.app.upgrade. We could make a version jump to plone.app.upgrade 5.1.x, although it should be understood that a theoretical future version plone.app.upgrade 5.2.4 should still work fine on Plone 5.0.6: fixes can be done for earlier upgrade steps.
• For Plone 5, support only upgrades from Plone 4.0 or higher. Maybe 4.3 or higher. Remove older code.
• Upgrades that are added to the 4.3 code should also be added to the Plone 5 code, but that won't be much.

Is this a sane idea?

@esteele: Any comments?

[thet]

If we would always only support migration from the latest minor version, we could really get rid of a whole bunch of dependencies. Archetypes for example.

[jensens]

Yes, a big plus one to only support the migration path from the last major version series (current would be 4.0 final to 5.1a2).
The current situation implies a migration form a 2.5 to 5.1 just works in one step. This might be true for an unmodified vanilla Plone - but I have my doubts.
Also it would make it much easier to cope with removal of ancient code in our code base.

[thet]

Imo we could even support only minor versions like 4.3 to 5.0 or 5.0 to 5.1. But supporting major versions would be an improvement too.

[tisto]

We already had this discussion some time ago. We used to branch plone.app.upgrade before we unified it, because backporting changes became too complex to maintain (cc @davisagli).

If I recall correctly we decided that we keep a unified plone.app.upgrade but will drop the 2.5 and all 3.x migrations (except 3.3.x) after releasing Plone 5.

[jensens]

@tisto IIRC thats roughly what we agreed on, so kicking out 2.5 and 3.x is fine.

I doubt anybody has an advantage if we keep the latest 3.3.x, I would start with 4 final to keep things simple. Also it is easy to communicate to always upgrade from one major to the other.

Or did I miss some case where one might want to directly upgrade a latest 3.3.x to a latest 5.x?

[thet]

I would not recommend anyone to do so :)

[thet]

we could also use extra requires and zcml conditionals. That might help in restricting the upgrades to the ones you need for your project, if you want to.

On Sat, Sep 24, 2016 at 10:35 AM -0500, "Jens W. Klein" [email protected] wrote:

@tisto IIRC thats roughly what we agreed on, so kicking out 2.5 and 3.x is fine.

I doubt anybody has an advantage if we keep the latest 3.3.x, I would start with 4 final to keep things simple. Also it is easy to communicate to always upgrade from one major to the other.

Or did I miss some case where one might want to directly upgrade a latest 3.3.x to a latest 5.x?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.