Hi,
Eike and I have been trying to address problems in Oomph related to
the Mars Mac App layout changes and we're concerned that there
appears to be a general problem with a lack of semantic version
changes in bundles that have modified contents, in many cases not
just very minor content changes but rather major behavioral
changes. For example, it's clear that the p2 eclipse publisher is
significantly changed by this commit:
http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=1b96ce896c49151b0e20fa49ba680d08415cca8f
In fact, this commit changed the MANIFEST.MF of the eclipse
publisher itself:
http://git.eclipse.org/c/equinox/rt.equinox.p2.git/diff/bundles/org.eclipse.equinox.p2.publisher.eclipse/META-INF/MANIFEST.MF?id=1b96ce896c49151b0e20fa49ba680d08415cca8f
I.e., it is changing the BREE but it does not change the version
number of the MANIFEST.MF.
The last time the semantic version of this MANIFEST.MF was changed
was by this commit:
http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=c847dee6f33950f48ecd1d8eca18729f6ffc470f
I.e., way back for Kepler. The versioning guidelines are pretty
clear that a content change requires at least a service increment:
https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment
I've not investigated more deeply, but my impression is that there
is a general pattern of forgetting to increment bundle versions when
the contents have changed. Comparing Mars M6 (left) with Luna SR2
(right) I see very few things have been incremented, but surely
there have been many changes.

Note the red outlined case where the Mars version actually has a
smaller version number, 3.9.0, than the Luna version on the right,
3.9.1. That's very wrong.
I hesitate to point out that Oomph has a version management tool for
detecting when version changes don't match up with content changes.
I know other teams regularly increment all versions at the start of
a release, which granted is not ideal. But failing that, it's a
difficult problematic to manage manually such changes and it's clear
that it's not being handled very well because this isn't the first
time during the release cycle that this issue has come up for the
platform...
In case you're wondering, we're particularly concerned about this
because in Oomph we'll need to detect whether we're installing a
product with a newer or older version of the bundles that support
the new versus the old layout. We're not even sure which
representative bundle's version test though it seems clear we must
not be relying just on a build qualifier change to test for
content/behavior changes. For us it would be ideal if these things
were properly incremented for the final M6 repository contents...
Regards,
Ed
|