[MAGNOLIA-3252] Version should not ignore SNAPSHOT classifier Created: 15/Jul/10  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia
Component/s: updatemechanism
Affects Version/s: 4.3.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Nils Breunese Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
caused by MAGNOLIA-1665 updatemech : module version stored in... Closed
relation
is related to MAGNOLIA-1631 Warn user when installing snapshot ve... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

We have used some Magnolia and STK/ETK SNAPSHOT jars for a while on our central development repository and upgraded to final releases when they became available. The version numbers in the configuration workspace still say "4.3.2-SNAPSHOT" and "1.3.1-SNAPSHOT" though.

Javadoc for info.magnolia.module.model.Version says: "Format is x.y.z-classifier. y,z and classifier are optional. The classifier string is ignored in version comparisons." I feel this could result in problems if version handler are changed during the SNAPSHOT phase. We install the SNAPSHOT jar, the module version is set to a SNAPSHOT version in the configuration workspace, but when we later upgrade to the release jar the Version class doesn't think the release version number is more recent, so the version handler won't be executed again.

I feel it would be good to modify the Version class to reflect that version "x.y.z" is more recent than "x.y.z-SNAPSHOT".



 Comments   
Comment by Bert Leunis [ 19/Jul/10 ]

I'll add some extra info that was exchanged on the user list.

Bert said: The versionhandlers should recognize the move from 1.3.1-SNAPSHOT to 1.3.1 as an upgrade. Is that correct?

Jan answered:
The answer is "it depends". When you work with the snapshots you are using a module that is in an undeterminate state. It might be in early phase of the version development and there are not update tasks yet or it might be in the very late stage and all the update tasks are already in place. In the first case you want to run the update tasks when moving to final version, in the second you don't. There is no signature for each task so it is not possible to determine whether given task was executed or not. Decision is in this case up to you as a maintainer of the system.
If you don't want to have any tasks executed, leave everything as is and just replace snapshot jar with the final one. If on the other hand you want to execute the update tasks, change the version number of given module to the previous version and after the restart update tasks will be executed.

Bert replied: I see. But apart from that, shouldn't at least the version number be updated?
It looks very strange to have a jar with version 4.3.2 on the classpath, but a version number in the configuration of 4.3.2-SNAPSHOT.

Jan replied: Yeah, it should be.

Comment by Leo Lozes [ 22/Feb/13 ]

It looks like this is not going to be fixed soon, so can you at least provide a manual about how to handle this situation?
We use Maven in all our projects, and we are used to use SNAPSHOT as long as a module is in development, and then release it when it's ready. The problem being mainly about testing environment. If I installed my CustomModule 1.0-SNAPSHOT, Magnolia will not update to CustomModule 1.0 when it's released. Should we then just skip this version and release the 1.1? I suppose you have some workaround for your own developments, or use a different approach.

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:44:41 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.