[releng] Increment all Kepler plugin/feature minor versions #989
Comments
|
By Ed Willink on Nov 04, 2012 12:00 bug/393508 bumps all minor versions. Please review. After build on branch tests, the whole thing can be installed on 4.2 SR1 Modeling EPP plus OCL Examples and Editors but strangely, installing just All-In-One fails with a 3.2.1/3.3.0 conflict on ...ocl.examples.xtext.base -- ridiculous. One for Bug 380221. |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 06, 2012 03:54 Hi Ed, I might do the review during this week. Perhaps, tomorrow. Cheers, |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 07, 2012 08:54 Hi Ed,
I'm not very agree with the policy. If a plugin doesn't change it should not be increased. For every client which strictly depends on a plugin version we are unnecessarily forcing them, to revise their dependencies. I agree that the policy is the easier for us, but I believe it's not the proper one.
I think that Eike and/or Ed (Merks) were working on some enhanced tooling around this topic. We could ping him for an update.
I think it should not be very hard detecting which plugins need to be increased, by comparing for example the master branch with the previous milestone tag. Perhaps it could be a releng task (mine :P ) before building a milestone, so that he verifies each 6 weeks which plugin have changed (rather than with every developer commit). If my memory doesn't fail me, this is what I did for Juno SR1. If you agree, I could try the approach on bug/393508 branch. |
|
By Ed Willink on Nov 07, 2012 09:08 (In reply to comment #3)
Who does this. Surely depenedencies are blank or next major version. Gratuitous minor versions only cause some extra download traffic.\
No proper but it's better than our current incomnsistent/illergal versios.
Give it a try.
I'd certainly be interested to see your list of necessary changes to make M3 versions coherent. I'm not sure that want to use bug/393508 since you want to start again at master. Perhaps bug/393508b. |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 07, 2012 11:23
Comments:
... Running a the bug/393508b branch test build to verify. Noticeable change to mention:
|
|
By Adolfo Sanchez-Barbudo Herrera on Nov 08, 2012 05:06 Juno SR1 Modeling + OCL Examples is able to update the "OCL End User SDK" and "OCL Examples and Editors" features using the last bug/393508b test build result repository [1] After restarting Eclipse, I've also successfully installed the "OCL All-In-One SDK" feature. Comparing bug/393508b and bug/393508b the plugin/features which are not changed are the following:
Let me know if you want I merge the bug/393508b into master branch, as long as the bug/393508b is OK for you ;) Cheers, |
|
By Ed Willink on Nov 08, 2012 06:49 Hmm. What is a change? The simple GIT master/Juno compare shows many changes. Changed line-delimiters on undistributed source files are perhaps not significant, but an SDK user will see a change. So a downstream user with some checksumming algorithm may be deceived. Changed line-delimiters on distributed source files such as oclstdlib.ecore are logically unchanged but a user with a defective XML reader might notice. For Kepler, we have actually updated everything, so the universal version bumps are not inappropriate, so I think we should do them. In the future, the GIT master/Kepler compare easily identifies changes so could manually guide minimal update, but how do we guarantee to bump a master version when a maintenance bump occurs? (Sometimes fixes are only needed for maintenance, the master may be fixed by an inherited platform/EMF fix.) So after Kepler we want to see if Eike's tooling can be exploited. For the build features, the version may not matter to anyone, but I think we shiould keep things consistent; packaging.ant has changed. |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 09, 2012 04:40 (In reply to comment #7)
I think I did well by not anticipating the master merge ;)
I think you are missing the forth segment (qualifier)...
Yes, in principle, they are inappropriate. Why are we changing the versions ? The quick answer: we simply want to (must?) follow the http://wiki.eclipse.org/Version_Numbering guidelines. I was not considering the end-line as a change which merits even a service segment increase., but It looks like I should change change the affected plugins to a X.Y.100 version. On the other hand, I've assumed that we need a minor increase, when, perhaps, a simple service segment version increase is required. The problem, then, is that the committer is the ideal person to change the manifest version, because he/she exactly knows if a change merits the major/minor/service segment version increase.
This idea came to my mind, but I concluded that if a fix is done to a maintenance plugin, why not doing the fix in the master branch ?. Your inherited platform/EMF fix argument looks reasonable. Solution: porting segments version increases to the master branch. Extra overhead to releng? to the committer ? In this case, the motivation is not following version numbering policies, but allowing software updates across different Eclipse platforms.
I'd to know what "consistent" implies, to check the consistency in other plugins/features and ensure that things keep consistent. Anyway, I understand what you mean so these features will also be changed. My conclusion: I'm afraid that we need some kind of reasonable process, and then apply it. We have been talking about different concerns (version numbering policies, software updates, extra efforts, available tools, ...) and stakeholders (committer, releng, end-user,...). I'm not sure if we are missing something else, but I guess we have enough information to take a decision. Perhaps, knowing if every project may establish their own version numbering policy (i.e is what you are proposing) could help. In any case, as project leader I think it's your decision. I'll happily accept it, specially if it relaxes the releng efforts and errors proliferation :) Cheers, |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 09, 2012 04:45 To track Link of the thread which mentioned the tool to manage the plugin versions: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08026.html |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 09, 2012 04:54 In the oven: |
|
By Ed Willink on Nov 09, 2012 05:21 (In reply to comment #8)
At last. An example that enables me to understand what the +0.0.100's are really for. So, until we have an automated policy as in Bug 393954, we start each new release cycle by adding 0.0.100 all round, guaranteeing to avoid maintenance release conflicts. We then gradually change the +0.0.100 to +0.1 as we notice that real changes have been made, and know that the change has already been made if its not a 100 number. New line changes are satisfactorily covered by +0.0.100 and do not merit promotion to +0.1. I'll prepare a new patch halfway beween bug/393508 and bug/393508b. |
|
By Ed Willink on Nov 09, 2012 06:25 (In reply to comment #11)
bug/393508a building on Hudson now. I've endeavoured to set plugin versions to accommodate retrospective oversights so all the longstanding plugins that originate at: 4.0 are now 4.1 or 4.0.100 New-to-Juno plugins are 1.1 or 1.0.100. In doing this ocl.uml.edit has gone from 3.x to 4.0.100 to correct the missing major version change to 4.0 that should have accompanied the other UML 4.0 changes. |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 12, 2012 04:53 Hi Ed, Giving the new version numbering policy, I +1 it. I'll merge your branch and start with the Kepler OCL Core M3. Cheers, |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 12, 2012 04:58 mmmm When comparing the branch with master one, I've noticed that some features.xml have reinstated the windows end-line. I'll do some fixes around. |
|
By Ed Willink on Nov 12, 2012 05:09 (In reply to comment #14)
I try to remember to do Convert all linendings before serious commits, and sometimes report bugs against tools that are not respecting project settings. EMF editors have a fix committed. |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 12, 2012 05:23 (In reply to comment #15)\
So there is not any hidden workspace property, which helps here (I've just looked for it with no luck). I guess this is a Feature Manifest Editor faulty, then. I'll raise a bug to PDE. Perhaps, this a cross-text editors issue, although I'm not experienced enough to assert it. Changes committed and pushed to branch.... I'll start with the S-build duties. Cheers, |
|
By Adolfo Sanchez-Barbudo Herrera on Nov 14, 2012 11:47 I've tested the update of Juno SR1 with our final OCL Kepler M3 (using our milestones repository) and it's ok. Resolving as fixed. I've noticed that bug/393508 branches have been removed, by you I guess, as well. |
|
By Ed Willink on May 27, 2014 09:43 CLOSED after more than a year in RESOLVED state. |
|
By Ed Willink on May 27, 2014 09:52 and CLOSE |
| --- | --- |
| Bugzilla Link | 393508 |
| Status | CLOSED FIXED |
| Importance | P3 major |
| Reported | Nov 04, 2012 10:55 EDT |
| Modified | May 27, 2014 09:52 EDT |
| Reporter | Ed Willink |
Description
While investigating Bug 380221, it appears that we have been failing badly in regards to maintaining plugin/version changes as corrolaries of class edits. I can see faults attributable to all three committers.
As a consequence Kepler M2 cannot be installed on Juno SR1 because M2 still has a 4.0.0 where SR1 has a 4.0.1.
Clearly intelligent minimal update is too hard for us.
Clearly our current tooling does not detect our failings.
Therefore let's just do a minor update on everything early in each release cycle so that no further updates (other than major) are needed.
The text was updated successfully, but these errors were encountered: