[MGNLPUR-73] Update Pom dependency & Version Handler in order to use the new migration process Created: 19/Oct/12  Updated: 02/Dec/12  Resolved: 30/Nov/12

Status: Closed
Project: Magnolia Public User Registration
Component/s: None
Affects Version/s: 1.4.1
Fix Version/s: 1.4.2

Type: Task Priority: Neutral
Reporter: Eric Hechinger Assignee: Eric Hechinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLMIGRATION-141 Migrated Modules configuration: PUR Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

Add dependency on the POM to the migration module.
Create a new version handling task in order to migrate configuration.
Add an Extra Migration sub Task (Post Migration specific task).



 Comments   
Comment by Jan Haderka [ 26/Nov/12 ]

The task says "update pom dependency for migration module. But also form module version is updated. Why?

And again we are adding update task to the version that was previously released. You need to document why we do it and why it will not cause any side effects.

One more thing I've noticed - when adding dependency to migration module, you are not adding dependency to module descriptor. Is this ok? Does it really not matter whether migration module is installed before or not?

Comment by Eric Hechinger [ 30/Nov/12 ]

Form update is my mistake. As we are not using new Form features we should keep the previous version.

Add a migration task in the version handler in order to migrate the PUR module from 4.4.6 to 4.5.7 and higher.
Magnolia 4.4.6 shipped PUR 1.3.1
Magnolia 4.5.0 shipped PUR 1.4

If a Magnolia instance is updated from 4.4.6 to 4.5.7, the version handler will take care of the migration of the module.
If a Magnolia instance was already updated let say from 4.4.6 to 4.5.6 (Version 1.4.1 of the PUR module) and we want now to update to Magnolia 4.5.7, in this case, the version handler's will not run the migration.
Migration already took place during update from 4.4.6 to 4.5.6. and should not run again.
This is exactly what we expected.

Generated at Mon Feb 12 06:42:49 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.