Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Specifying version requirements


Pascal, or others who might know ....

What is the effect of not specifying these constraints? Does it default to "any" .... so, the danger is its just defined too broadly? Picking the highest available at runtime? Leading to a danger of hard to maintain install bases? Or, is it something even worse? (such as. "randomly picks all from possibilities each time its ran"?)

Thanks,





David M Williams/Raleigh/IBM@IBMUS
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

05/31/2006 03:25 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] Specifying version requirements






Pascal. This looks like a very helpful tool and I plan to use it soon myself.


Might I request .. can it and the source be attached to a bugzilla? Or ... is it already in CVS somewhere? You know I trust you  :)  but as a matter of policy I hate to execute "class" files from a mailing list, especially without source.


Another advantage of a bugzilla is then people  could suggest, or contribute back, feature enhancements. For example, I'd possibly like a version that gives the "conservative" range instead of the "api range".




And, will even suggest the reasons for it here ... for public scrutiny.  In WTP at least, I think we use enough non-API (mostly within ourselves, not too much from base or pre-reqs) that I'd like to do a "mass update" that used the conservative range. Then component owners (those with more knowledge of the code) could "open it up" if they know for sure they do not use any non-API, or otherwise untrustworthy code.


I think the conservative approach is safest, as we get used to this new versioning, since, as I see it, the cost of making an error is worse if give to wide a range.
       Cost if too wide: clients could end up "broken" and have to wait for fixed version, get the fixed version, might even have to uninstall and re-install everything, with fixed version, to get working again.
       Cost of too narrow: an update might have to be provided that was not technically really necessary, just to bump up a version number range.



Any comments/suggestions?







Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

05/29/2006 02:32 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
cross-project-issues-dev@xxxxxxxxxxx
cc
Subject
[cross-project-issues-dev] Specifying version requirements








Hi all,

Earlier this year, the eclipse team put together guidelines on how to version plug-ins: http://www.eclipse.org/equinox/documents/plugin-versioning.html.

These guidelines have been adopted by a lot of the callisto teams, however most of them (including the SDK team) missed the fact that specifying properly its version was only part of the problem and that it was equivalently important to specify ranges when requiring plug-ins.


Therefore, in order to help all of you specify the ranges on all the required plug-ins on time for callisto, I have written a little plug-in that will propose values for all the missing ranges. The generated values assume that you are only using APIs however if you know otherwise you should specify a tighter range by lowering the value for the upper bound.

Example of an output:

bundle org.eclipse.cdt.ui                                <--------- plug-in name which has the problem

      org.eclipse.ui.ide;bundle-version="[3.2.0,4.0.0)"        <--------- proposed value

      org.eclipse.ui.views;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.jface.text;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.ui.workbench.texteditor;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.ui.editors;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.ui;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.core.resources;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.search;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.compare;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.cdt.core;bundle-version="[3.1.0,4.0.0)"

      org.eclipse.ui.console;bundle-version="[3.1.100,4.0.0)"

      org.eclipse.core.filebuffers;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)"

      org.eclipse.help;bundle-version="[3.2.0,4.0.0)"


How to use the tool:

- copy the attached jar in your plugins folder

- run the following command

      java -jar startup.jar -clean -application org.eclipse.core.runtime.versionchecker.dependencyChecker


If you want to only check the dependency for a limited set of plugins, you can specify the -filter option and specify a regexp matching the bundle names. For example "-filter .*cdt.*" will only match the CDT plug-ins.


Regards,

PaScaL

[attachment "org.eclipse.core.runtime.versionchecker_1.0.0.jar" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top