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

upgrade/replace for Plone 5: Working Copy Support (Iterate) 2.1.18 #518

Open
paregorios opened this issue Jul 12, 2024 · 5 comments
Open

Comments

@paregorios
Copy link
Member

paregorios commented Jul 12, 2024

This addon is currently active in our build. We use working copy support extensively, and will need it to work in 5.1.

@alecpm
Copy link

alecpm commented Jul 18, 2024

This is now core Plone functionality and will be upgraded automatically with Plone (though it needs to be explicitly enabled). It's worth noting unless custom special handling is implemented, all existing working copies/versions will be lost during the migration process.

@paregorios
Copy link
Member Author

@alecpm have we incorporated into 5.1 buildout or whatever the "explicit enablement" for this addon? If so, can this ticket be closed?

@alecpm
Copy link

alecpm commented Oct 1, 2024

Since it’s already enabled, it should continue to be enabled. @paregorios Do you have thoughts on whether you want to attempt to preserve versions/working copies during the type migration? I would recommend against it.

@paregorios
Copy link
Member Author

So this will be a ticket for me to clear out working copies throughout the site before we do the final migration.

@alecpm if there are working copies hanging around at migration, and we choose not to preserve them, will there be any weird stuff brought forward or funky database conditions? i.e., do we have to find and purge them all, or can we just let them get trashed during the migration?

I have no problem dumping versions.

@alecpm
Copy link

alecpm commented Oct 1, 2024

I think we can choose to dump versions, keeping them around can cause issues because they will have the wrong underlying class. It's probably best to manually remove any working copies floating around before final migration. I don't believe there's a process for handling those automatically. @sauzher does that sound right to you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants