Max,
That would definitely help in some cases, but many cases are service
level related. Of course that's always the case for service
releases, and with the common/recommended practice of +100 service
level increments it's a very common problem. I believe that Tycho
can/does support qualifier expansion based on git commits, so it's
certainly possible in principle to know there was a commit in a
bundle and that there has been no commit to the MANIFEST.MF, i.e.,
one could write a fairly brute force tool. The problem is that not
every file in the bundle necessarily results in changes to in the
binary version of the bundle (e.g., a .gitignore change) so there
could be false alerts, nor does this help with feature maintenance
without deeper dependency analysis. In the end it's really a very
hard and nasty problem so no one should take offense to my pointing
out the platform's problems. I'm quite sure we're pretty much all
are making such mistakes and will continue to do so, unless we use
tools...
Regards,
Ed
On 25/03/2015 12:17 PM, Max Rydahl
Andersen wrote:
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
_______________________________________________
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
|