See discussion about it here: http://dev.eclipse.org/mhonarc/lists/tycho-dev/msg01236.html
Currently it fails hard when version hasn't bumped since that's the policy we have in jbosstools to avoid this issue (if we are rebuilding anyway then ensuring bumping is simpler) but this should be trivial to vary it's strictness. /max http://about.me/maxandersen > On 27 Mar 2015, at 06:38, Ed Merks <[email protected]> wrote: > > Max, > > Comments below. > >>> On 26/03/2015 12:52 PM, Max Rydahl Andersen wrote: >>> On 25 Mar 2015, at 14:06, Ed Merks wrote: >>> >>> 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, >> >> which is why our plugin check simply asserts that between a release and the >> next there must be a bump if the binary changed. I don't really care if you >> just added a .gitignore - your build has then changed and you are producing >> new bits :) > I see, so you mean it literally checks that the jar itself is simply > different (which could be just because a new version of the compiler produces > different byte code)! It does seem better to be cautious/conservative > failing any more perfect alternative... >> >> I know its brute force but I find it better than having multiple different >> binaries with the same version released unwillingly. > Absolutely, I didn't know about this! Probably not many other people know > about it either. Where could we find out more how to use it? >> >>> 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... >> >> /max >> >>> 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) >>>> >>>> >>>> /max >>>> http://about.me/maxandersen >>>> >>>> >>>>> On 25 Mar 2015, at 12:02, Ed Merks <[email protected] >>>>> <mailto:[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] >>>>> <mailto:[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 >> >> >> /max >> http://about.me/maxandersen >> _______________________________________________ >> 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
