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) /max http://about.me/maxandersen > On 25 Mar 2015, at 12:02, Ed Merks <[email protected]> wrote: > > 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 <[email protected]> >> To: Cross project issues <[email protected]> >> Date: 24.03.2015 18:57 >> Subject: [cross-project-issues-dev] Equinox Bundle Version Concerns >> Sent by: [email protected] >> >> >> >> 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 >> [email protected] >> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
