Switch qualifier replacement method for UML2 builds to lastModified

[eclipse-uml2-bot]

| --- | --- | | Bugzilla Link | 450868 | | Status | REOPENED | | Importance | P3 enhancement | | Reported | Nov 10, 2014 13:00 EDT | | Modified | Nov 11, 2014 09:28 EDT | | Reporter | Ed Willink |

Description

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.

[eclipse-uml2-bot]

By Kenn Hussey on Nov 10, 2014 13:19

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.

[eclipse-uml2-bot]

By Ed Willink on Nov 10, 2014 14:04

If there is no change, you have a releng bug. The qualifier should be unchanged.

[eclipse-uml2-bot]

By Kenn Hussey on Nov 10, 2014 15:47

New qualifiers are produced for every UML2 build and have been for years. I agree that it’s not optimal; contributions welcome.

[eclipse-uml2-bot]

By Ed Willink on Nov 10, 2014 17:51

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.

[eclipse-uml2-bot]

By Kenn Hussey on Nov 10, 2014 19:30

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).

[eclipse-uml2-bot]

By Ed Willink on Nov 11, 2014 02:19

(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.

[eclipse-uml2-bot]

By Ed Willink on Nov 11, 2014 04:54

(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.