Community
Participate
Working Groups
The M3 version of org.eclipse.uml2.uml.resources is still 5.0.0 but has a new qualifier. This is bad practice as can be anticipated if SR1 or SR2 introduces a 5.0.1 that will then be out of order. Changed code should be either 5.0.100 or 5.1.0 or 6.0.0.
The code in org.eclipse.uml2.uml.resources has not changed. If/when it does in Luna SR2 or Mars, the version will be changed appropriately (to 5.0.2 or 5.0.100/5.1.0) per the usual convention.
If there is no change, you have a releng bug. The qualifier should be unchanged.
New qualifiers are produced for every UML2 build and have been for years. I agree that it’s not optimal; contributions welcome.
I think that versions are preserved by the prevailing repo, so if the new release job is a migration of the previous it continues rather than restarts.
I’m not sure what exactly you mean by “new release job”, but I had to switch to the ‘buildTImestamp’ qualifier replacement method several years ago when I ran into problems with the ‘lastModified’ alternative in Buckminster. Have you managed to use the latter consistently with success? Note that the current approach should still result in correct updates, although it may result in updating more things than strictly needed (with the same content).
(In reply to Kenn Hussey from comment #5) >I ran into problems with the ‘lastModified’ alternative in Buckminster. Have > you managed to use the latter consistently with success? We've been using qualifier.replacement.*=generator:lastModified generator.lastModified.format='v'yyyyMMdd-HHmm unchanged for over four years. For the last two years I have done an eager +0.0.100 to avoid accidental update failures so may not have noticed problems. When we merged our +1 and +3 builds to do a preemptive +1 build despite a +2 dependency on Xtext with a follow up no-change +3 rebuild, I needed the +1 and +3 builds to be comparable and unchanged. They were apart from the old-fashioned use of about.ini and about.mappings which are auto-edited thereby giving you auto-different builds. So your changed versions may have at least trivially different content. Eliminating about.ini and about.mappings may solve your problems. The consequence is that the displayed description for features in the Help->Installed Contents changes slightly. Instead of your internally mutated version, you can fall back onto a platform autogenerated version. Compare OCL and UML2 feature descriptions.
(In reply to Kenn Hussey from comment #5) > I’m not sure what exactly you mean by “new release job” If you have a build job named xxx-luna, then you can either rename to xxx-mars or create a new job named xxx-mars. Renaming should preserve continuity, whereas creating a new job may be discontinuous unless you take care to do a build referencing the old repo before migrating to a new reference repo.
