Community
Participate
Working Groups
To avoid accidental delivery of changed same-version plugins for Luna milestones, all version numbers should be bumped by 0.0.100. Then when edits happen on a x.y.100, 0.1 should be added, but forgetting does not cause conflicts.
Version changes pushed to branch edw/410586 for review.
(In reply to comment #0) > To avoid accidental delivery of changed same-version plugins for Luna > milestones, all version numbers should be bumped by 0.0.100. > > Then when edits happen on a x.y.100, 0.1 should be added, but forgetting > does not cause conflicts. Hi Ed, I don't think it's a reasonable idea to bump all plug-ins to 0.0.100 Only plug-ins with changed content should increase it's version. -1 for the change
Sergey: Please reconsider. a) the Eclipse version numbering policy[1] requires +0.0.100 for any touch to any continuing development streams. b) we had significant problems in QVTo and less in OCL releases where at M1/M2 a developer neglected to update all the ancestral version numbers. Consequently when SR1 came along, there were two different development streams contributing the 'same' version number and the consequent date qualifier gave at best unpredictable results, at worst gave P2 a major headache. [1] http://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment
See further discussion on https://bugs.eclipse.org/bugs/show_bug.cgi?id=410589.
Hi Ed, (In reply to comment #3) > Sergey: Please reconsider. > > a) the Eclipse version numbering policy[1] requires +0.0.100 for any touch > to any continuing development streams. Version numbering policy states that version is updated only for plug-in which contains some changes. No bulk update of plug-ins version after the release. I remeber there was discussion in cross-project mail list about the same subject several years ago. Common decision was that it's not a good practice to update version of all plug-ins (regardless of actual changes) between releases. > > b) we had significant problems in QVTo and less in OCL releases where at > M1/M2 a developer neglected to update all the ancestral version numbers. To tell the truth I don't know / remember on what problems with QVTo you are referring to. > > Consequently when SR1 came along, there were two different development > streams contributing the 'same' version number and the consequent date > qualifier gave at best unpredictable results, at worst gave P2 a major > headache. Of course you're right and plug-in version should be correctly updated but only for affected one. Btw, scheme which is used for qualifier construction prevents most of possible problems / conflicts with version. > > [1] > http://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment
(In reply to comment #4) > See further discussion on > https://bugs.eclipse.org/bugs/show_bug.cgi?id=410589. As far as I see Adolfo also does not like bulk update of version numbering.
(In reply to comment #5) > > b) we had significant problems in QVTo and less in OCL releases where at > > M1/M2 a developer neglected to update all the ancestral version numbers. > > To tell the truth I don't know / remember on what problems with QVTo you are > referring to. There were so many version number problems when getting QVTo going thjat I forget quite which came when. > Of course you're right and plug-in version should be correctly updated but > only for affected one. > Btw, scheme which is used for qualifier construction prevents most of > possible problems / conflicts with version. But only if committers do it right which we never do. Since you reject my advice on how to ensure that this regular problem doesn't arise, I take it that you will now take over the releng job for which I have no funding.
(In reply to comment #7) > > Since you reject my advice on how to ensure that this regular problem > doesn't arise, I take it that you will now take over the releng job for > which I have no funding. Hi Ed, Excuse me if it looks like I too insist on this. But I still think that version should be updated only for plug-in with changed content. About releng - you are absolutely right that I should take care of it. I will try to proceed in such a way to avoid mistakes in this tangled (at least for me) area.
> > About releng - you are absolutely right that I should take care of it. I > will try to proceed in such a way to avoid mistakes in this tangled (at > least for me) area. I see two ways to facilitate this: a) At Mx build time, comparing master with Mx-1 tag. - This should give you changed plugins, and then you should be able to verify that the corresponding manifest have increased their versions. - Steps to view the comparison: 1. In GIT repositories view select master branch 2. Ctrl + Select desired tag 3. Right click -> "Syncrhonize with each other" - Two styles to verify changes 1. Comparing with SR0tag should to quickly give a quick way to compare and verify manifest.files. However, at M7 for examples you will have a lot of changes to verify 2. Comparing with Mx-1 tag gives you less changed plugins to verify. However, the verification of the manifest file is harder since it may not appear in the synchronization view (Because it was changed in a previous milestone) b) Try the Version Management Tool implemented [1] by Eike, which should warn you when you change a plugin and you don't correctly pump the service segment version. I guess this works in a similar way API tooling does. Cheers, Adolfo. [1] http://wiki.eclipse.org/CDO/Version_Management_Tool
