Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In 6.0 alpha, upgrade all profiles to minimum versions #3346

Closed
mauritsvanrees opened this issue Oct 27, 2021 · 3 comments · Fixed by plone/plone.app.upgrade#289
Closed

In 6.0 alpha, upgrade all profiles to minimum versions #3346

mauritsvanrees opened this issue Oct 27, 2021 · 3 comments · Fixed by plone/plone.app.upgrade#289
Assignees

Comments

@mauritsvanrees
Copy link
Member

Let's picture ourselves a few years from now. Plone 6.2 is out. We migrate a site from Plone 5.2.0 to 6.2.0.
We go to `@@plone-upgrade`` and run the upgrade. What happens?

This means that you first upgrade to 6.2, and then you apply an upgrade step from, for example, plone.app.contenttypes which was written around the time when 6.0 alpha was first out.

This is what we have been doing since Plone 5.0rc1 when I introduced this add-on list. It has worked fine I think.

But I can see the danger that an upgrade step that works now, will not work when run on a 6.2 site.
Or it may undo a plone.app.upgrade fix from 6.1.

My idea:

  • Take the list of add-ons.
  • Create an upgrade step in plone.app.upgrade for CMFPlone 6.0.0 alpha 2.
  • In this step, upgrade the profiles of all those add-ons to the metadata revision that they currently have.
  • We could instead do this in the first beta or first rc.
  • Probably do the same in the future for Plone 6.1.

The result is that all upgrade steps are run in roughly the order that they were meant to be executed.
Does this sound useful and sane?

@mauritsvanrees mauritsvanrees self-assigned this Oct 27, 2021
@ale-rt
Copy link
Member

ale-rt commented Oct 28, 2021

Yeah, I see your point.
This sounds useful and sane.

Just adding food for thoughts: it might also be interesting to run the upgrades in a ftw.upgrade fashion, where upgrade steps run in an order based on the timestamp included in the name.

That would also help people that work with coredev to keep their Data.fs uptodate.

@mauritsvanrees
Copy link
Member Author

Just adding food for thoughts: it might also be interesting to run the upgrades in a ftw.upgrade fashion, where upgrade steps run in an order based on the timestamp included in the name.

I use bin/upgrade in probably all my projects. But I never bought into the way they create upgrade steps.

@mauritsvanrees
Copy link
Member Author

The code would be for example:

upgradeProfile("plone.staticresources", dest="208")

@pbauer is adding this one in plone.app.ugprade for ES6 as we speak.

mauritsvanrees added a commit to plone/plone.app.upgrade that referenced this issue Apr 15, 2022
mister-roboto pushed a commit to plone/buildout.coredev that referenced this issue Apr 15, 2022
Branch: refs/heads/master
Date: 2022-04-15T09:46:17+02:00
Author: Maurits van Rees (mauritsvanrees) <maurits@vanrees.org>
Commit: plone/plone.app.upgrade@0458c73

Upgrade profiles of core Plone modules to specific versions.

Fixes plone/Products.CMFPlone#3346
Added tests.

Files changed:
A news/3346.feature
M plone/app/upgrade/v60/alphas.py
M plone/app/upgrade/v60/configure.zcml
M plone/app/upgrade/v60/tests.py
Repository: plone.app.upgrade

Branch: refs/heads/master
Date: 2022-04-15T17:32:40+02:00
Author: Maurits van Rees (mauritsvanrees) <m.van.rees@zestsoftware.nl>
Commit: plone/plone.app.upgrade@ee807bd

Merge pull request #289 from plone/maurits-upgrade-to-specific-versions

Upgrade profiles of core Plone modules to specific versions.

Files changed:
A news/3346.feature
M plone/app/upgrade/v60/alphas.py
M plone/app/upgrade/v60/configure.zcml
M plone/app/upgrade/v60/tests.py
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants