Community
Participate
Working Groups
In Helios SR1, it looks like OCL released: 3.0.0.R30x_v201008251030-4--7S41yaw312119362141 and in SR0, the version was: 3.0.0.v201005061704-4--7w312116172815 but since the qualifier are compared as strings, 'v' is newer than 'R' (in the ASCII table), so the SR0 build looks newer than SR1.
Fortunately the only real changes are in the Examples where we went to 3.0.1, so hopefully this is cosmetic. Does it actually cause problems?
(In reply to comment #1) > Fortunately the only real changes are in the Examples where we went to 3.0.1, > so hopefully this is cosmetic. Does it actually cause problems? The only side effect of this is that people may not 'update' to SR1. In some cases they will (if another feature had a 'strict' dependency on 3.0.0.R30x_... then this feature will pull you along too. But if someone just had OCL installed and they checked for updates, this won't look like an update. But this brings up a more interesting problem that I'll raise with the AC. We put a lot of faith in our version numbers, and it's very easy to get these wrong. Most of the Eclipse community doesn't know (nor should they care) about the subtleties of version numbers. I think the Release Train should have some automatic checks in place that help pervert this. As a side node, if something changed in your 30x branch, then your version should likely be: 3.0.1.R30x_v201008251030-4--7S41yaw312119362141 (notice the 1). If nothing changed in the branch, then the version should be exactly the same as SR0.
We indeed went to 3.0.1 for anything that changed. I had not come across the x.y.x.rNN policy which Adolfo adopted from the version number recommendations, so I think the 'numbers' we have are actually 'correct'. It would seem that to avoid this problem the AC must 'recommend' versions as x.y.z.V... and re-versions as x.y.z.r... to guarantee that r is after V.
(In reply to comment #3) > We indeed went to 3.0.1 for anything that changed. > > I had not come across the x.y.x.rNN policy which Adolfo adopted from the > version number recommendations, so I think the 'numbers' we have are actually > 'correct'. > The feature in question is: org.eclipse.ocl.uml If *nothing* changed, then the version number for SR1 should be *exactly* the same as it was for SR0 (which is not the case). This is important in p2, since p2 will not download the new version (why should it, nothing changed?). If *anything* changed, then the version number should have been incremented to 3.0.1.qualifier. > It would seem that to avoid this problem the AC must 'recommend' > > versions as x.y.z.V... > and re-versions as x.y.z.r... > > to guarantee that r is after V. While this would fix this particular problem, I don't think the AC 'recommends' any particular qualifier scheme. Looking at the platform build, they have qualifiers that start with I, v, V, R and r. I brought up the need for better education / tooling around release versioning with the AC (bug 327830).
Ian, Your point must be the reason why the MDT/OCL features doesn't automatically updates from 3.0.0 to 3.0.1. It's needed to "manually update" the component in the "Install new software" wizard. There was a discussion about this issue in the mdt.ocl-dev newsgroup in which I didn't find any conclusion about the cause. Regarding why this version was established. I only followed the recommendations in the version numbering wiki page entry: http://wiki.eclipse.org/Version_Numbering#When_to_change_the_qualifier_segment . It looks like it was not a good decision... Regards, Adolfo.
(In reply to comment #5) > Ian, > > Your point must be the reason why the MDT/OCL features doesn't automatically > updates from 3.0.0 to 3.0.1. It's needed to "manually update" the component in > the "Install new software" wizard. There was a discussion about this issue in > the mdt.ocl-dev newsgroup in which I didn't find any conclusion about the > cause. > Yep, this would make sense > Regarding why this version was established. I only followed the recommendations > in the version numbering wiki page entry: > http://wiki.eclipse.org/Version_Numbering#When_to_change_the_qualifier_segment > . It looks like it was not a good decision... > I'm by no means a version expert, but I think the question is, why do you have a branch build if you have no changes? If there are absolutely no changes in the ocl.uml feature, then why is it in a branch? On the p2 team, we don't branch a bundle / feature until we need to make a maintenance change. And at this point, we update the micro number. As I mentioned earlier, you do this, then users won't be forced to download new bytes when nothing has changed. If only 10% of eclipse bundles changed from SR0 to SR1, then a user should only need those bundles. If everyone performed 'branch builds', even when nothing changed, then users are forced to download all of Eclipse when a new version comes out. > Regards, > Adolfo.
Ian: As you pointed out before it's probably a tooling/education problem. Our project plan/naive common sense implies that branches are created at the start of potential maintenance, to avoid mistakes for actual maintenance. I know that Adolfo had significant difficulties persuading the build to work at all, much aggravated by Hudson's instabilities. What he achieved was fantastic in the circumstances. It is quite mad for Eclipse to hope that between 20 and 50 releng engineers will manage to get these issues right. It is absolutely amazing that there is no 'API'/p2 tooling that validates release installs. Buckminster might be better, hopefully b3 will be.
(In reply to comment #7) > Ian: As you pointed out before it's probably a tooling/education problem. > > Our project plan/naive common sense implies that branches are created at the > start of potential maintenance, to avoid mistakes for actual maintenance. Yep, no argument here. I assumed we would create a branch for p2 right after 3.6.0 shipped too. I was told we don't, and only now do I realize why. > > I know that Adolfo had significant difficulties persuading the build to work at > all, much aggravated by Hudson's instabilities. What he achieved was fantastic > in the circumstances. It is quite mad for Eclipse to hope that between 20 and > 50 releng engineers will manage to get these issues right. It is absolutely > amazing that there is no 'API'/p2 tooling that validates release installs. Please don't take this as a criticism of your release engineering process. I've been working on p2 for over 2 years now, and barely understand the subtleties of versions. As I told the AC, we but a lot of faith in our version numbers, and most teams really shouldn't care. I'll continue to push on this issue to get better tooling support in the release train.
Hi Ian, Ed Taking these maintenance release issues up. If I was not clear enough. Thank you very much for this information, it has been very useful for me and it will be very helpful for me in the near future ;). I've checked that in the bugzilla you opened, the idea of including some tooling to detect backwards incompatibilites concerning the plugin/features version was supported. Do you know any other new concerning this ? (BTW, we actually use API tooling in our project) Regarding the problem of "changing" the version of unchanged plugins/features. Our Helios builds were based on athena CBI, which are usually based on a map file which relies on tags of our CVS. I think that the problem was that in one moment we manually tagged all our plugins/features in the BRANCH instead of using the Releng Tools to update said map file. Using said utility ONLY the modified plugins/features are tagged. If we strictly use the Releng Tools for our Helios SR2 builds we won't have this problem anymore. Concerning the problem of backwards incompatibility. It's obvious that we can't do anything of SR1 ;P. For SR2 we have two options (below, + means advantages/good. - means disadvantages/not so good) 1. Using 3.0.2.R30x_vYYYYMMDD. + The tags for the maintenance branch follow the same policy for SR1. + We have the tags organized for the maintenance branch so that they can be distinguished from the HEAD tags. - The MDT/OCL 3.0.2 SR2 would still have versions backwards incompatibilities with MDT/OCL 3.0.0. + Now, MDT/OCL 3.0.2 SR2 wouldn't have versions backwards incompatibilities with MDT/OCL 3.0.1. 2. Using 3.0.2.vYYYYMMDD. - The tags for the maintenance branch don't follow the same policy for SR1. - We wouldn't have the tags organized. Branch and Head tags would be undistinguished. + The MDT/OCL 3.0.2 SR2 wouldn't have the versions backwards incompatibilities with MDT/OCL 3.0.0. + The MDT/OCL 3.0.2 SR2 wouldn't neither have versions backwards incompatibilities with MDT/OCL 3.0.1. Any thought ? Regards, Adolfo.
I would go for 2) - functionally correct but inconsistent names.
Ian, Ed After thinking a little more on this. The only loser point from 1) is that Helios 3.0.0 users would have to do a manual update to obtain MDT/OCL 3.0.1. We previously assumed that the automatic update was not done because "R30x_v..." is lesser than "v...". However, the changed plugins also increment the service segment version so our main feature (org.eclipse.ocl.all.sdk) version "3.0.1.R30x_v..." is actually greater than "3.0.0.v..." I think we are missing something else thoughts ? Regards, Adolfo.
> I think we are missing something else The original problem was a changed 3.0.0 suffix in backwards order, because we build in a branch. Ideally the maintenance branch is only used once a plugin changes so that an unchanged re-build re-uses the suffix; we should try to do this post-Indigo. Most plugins have now moved beyond 3.0.0 so the original problem has gone. I would fix the problem for SR2 by bumping any plugin to 3.0.2 that could be earlier than SR0 or SR1 as far as p2 is concerned.
(In reply to comment #12) > > I think we are missing something else > > The original problem was a changed 3.0.0 suffix in backwards order, because we > build in a branch. Ideally the maintenance branch is only used once a plugin > changes so that an unchanged re-build re-uses the suffix; we should try to do > this post-Indigo. We have two different of points here: - Firstly, some 3.0.0 plugins suffered the backwardos order due to the use of the R30x_v suffix. But most features (including the "top feature") were 3.0.1. I'm not expert in P2 so the question is "Does P2 realizes that some plugins and features suffered from the backwards order problem in order to not to do the automatic update )"... if P2 only relies on the identifier "top feature" we are missing something else .... Ian do you have any extra knowledge concerning this ? - Secondly, I don't think that the problem was caused by the creation of the branch, but the manual tagging of all plugin and features and correspondent manual change of the ocl.map file. If I had strictly used the Releng Tools which automatically tag the changed plugins and feature, and automatically update the ocl.map file, we wouldn't have had this problem. Anyway, we have moved to buckminster which doesn't rely in any tag, map.file, etc so we won't have this specific problem in Indigo+1... I think it's good to create a maintenance branch with all the plugins > > Most plugins have now moved beyond 3.0.0 so the original problem has gone. > > I would fix the problem for SR2 by bumping any plugin to 3.0.2 that could be > earlier than SR0 or SR1 as far as p2 is concerned. This would surely save us about the problem of the "automatic update", but we would then have the problem pointed out by Ian in comment 4, since again unchanged plugins will have to be downloaded in SR2. Anyway: - If we don't know the cause why SR1 didn't properly automatically updated in SR1, I prefer to do your suggestion in those few plugins rather than not having an automatic update. - We can then use the R30x_v to have some coherent tags in the CVS concerning the Helios maintenance.... I'll do m-build to do warm up for the next week. Then I'll attatch a patch which will fix this backward order, problem using Ed's suggestion. Cheers, Adolfo.
Created attachment 186475 [details] Fixing patch The attachment increases the version of all 3.0.0 plugins and features to the version 3.0.2. Waiting for feedback about the conclusions above. Cheers, Adolfo.
Sorry, a minor correction in my comments > if P2 only relies on the identifier "top feature" I meant "if P2 only relies on the version of the "top feature" (our "OCL Extender SDK" whose id is org.eclipse.ocl.all.sdk)" Cheers, Adolfo.
Ed, No more feedback by Ian.... Do you +1 to apply the patch ? Cheers, Adolfo.
+1 but is it enough? We seem to be pushing all the useful plugins to 3.0.2, so why not all of them? Opening the Target Platform View shows all source plugins at < 3.0.2 - probably just awaiting a releng build a couple of examples plugins at 3.0.0, 3.0.1. e.g. ocl.doc, ocl.examples, ocl.examples.tests, olc.examples.parser.ocl
I've just noticed that org.eclipse.ocl.examples.common on HEAD is still 3.0.0 whereas it is 3.0.2 for maintenance. I guess all the HEAD plugins must go to 3.1.0.
Ed, As Ian commented in comment 4, we should not increase the version of those plugins which haven't not changed, otherwise they will be "updated" despite the fact that it's not necessary. On the other hand, we are increasing the version of those plugins/features whic went back on time... that is, every 3.0.0 plugins... 3.0.1 plugins don't require to be increased 3.0.2 because they are not suffering from said issue (In reply to comment #18) > I've just noticed that > > org.eclipse.ocl.examples.common > > on HEAD is still 3.0.0 whereas it is 3.0.2 for maintenance. > > I guess all the HEAD plugins must go to 3.1.0. True, I noticed that when checkign last Axel's build... As you suggest...every HEAD's 3.0.0 plugin/feature should be increased to 3.1.0 version (greater than the 3.0.2 one) to make them coherent with our last Helios SR2 release. Regards, Adolfo.
Created attachment 186981 [details] Fixing patch try2 It looks like a I missed a couple of projects when creating the patch. This should be the good one
Created attachment 186985 [details] Fixing patch for HEAD The following patch ensures that every plugin in the maintenance branch which has increased its version from 3.0.0 to 3.0.2, also set in the HEAD a 3.1.0 version
Changes committed to HEAD and R3_0_maintenance branch. Resolving as fixed.
Closing
