|Re: [cross-project-issues-dev] Equinox Bundle Version Concerns|
Max, Comments below. On 26/03/2015 12:52 PM, Max Rydahl Andersen wrote:
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...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 :)
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?I know its brute force but I find it better than having multiple different binaries with the same version released unwillingly.
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.../maxRegards, 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) mailto:ed.merks@xxxxxxxxx>> wrote: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 EdYou'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@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit_______________________________________________ cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx <mailto:cross-project-issues-dev@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit/max http://about.me/maxandersen _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top