We've contributed a plugin to tycho that fails build if the version number is unchanged between build and a baseline.
Maybe enable that in I builds to catch the very basic failures ? (It has much less overhead than full Api tools)
Dani,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=463077
My general concern is that version increment oversights seem to be a
general pattern which isn't surprising because it's hard to know
whenever you commit something if that's the first commit for the
current stream and therefore requires a version increment. Further
more, there are ripple effects, i.e., the increment for a
feature.xml is most often dictated indirectly by the largest
increment in any included bundle or feature, and again, it's hard to
know whether this has been done yet for the current stream. It
might even be the case that a service increment has been made
already, but a subsequent more significant change dictates
incrementing the minor version (or major version) instead, and then
that ripples up to all the including features and their including
features. In the case of the platform, such including features are
often in a different repository (and I know that there isn't really
anyone who does more than check out the projects for their local
area of interest).
I don't know how a human being can be expected to maintain this
level of complexity consistently and correctly. I know I'm
certainly not capable of that, so I use Oomph's version tool for EMF
to manage the bundle/feature service versions. I know API tools help
with major and minor versions, but even here either those tools
aren't being used or aren't diagnosing these problems properly (and
clearly can't do the job if no one is checking out the broader
source base). In any case, the tools themselves require attention
and maintenance (and documentation), i.e., setting up proper
baselines and checking out containing features, so that's
significant work as well. Not to mention the fact that in the case
of API tools, the impact on build time is, let's just say,
prohibitive to the point of wanting to turn it off most of the
time.
Regards,
Ed
On 25/03/2015 10:07 AM, Daniel Megert
wrote:
Hi Ed
You're right, the minor
version
needs to be increased when the BREE is changed as per https://wiki.eclipse.org/Version_Numbering#When_to_change_the_minor_segment.
Please file bugs if you see outdated bundle versions.
Dani
From:
Ed Merks
<ed.merks@xxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:
24.03.2015 18:57
Subject:
[cross-project-issues-dev]
Equinox
Bundle Version Concerns
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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[attachment "abhceiej.png" deleted by Daniel
Megert/Zurich/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|