Re: [cross-project-issues-dev] Specifying version requirements

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

When no constraints are specified, it
means that the plug-in can work against any version of the required plug-ins
(for example, EMF 2.2 should be able to run against eclipse 1.0 state that
it will run against all the version of eclipse that will come in the future
:-)) which of course is not true because of API changes, usage of internals,
etc.... For the end user it means that he/she can install a plug-in run
it and get random exceptions (NoClassDefFound, NoSuchMethod, etc,)  or
unexpected behavior when the plug-in was just simply not meant to run and
shoud have not resolved is the first place.
Of course one might say: "this
won't happen for callisto since we are all shipping on the same date".
 This is true but callisto is only one instant in time and as projects
starts shipping point releases on their own schedule, then the user problem
I was outlining previously will occur and the remedy to this will be another
synchronize release which will be somehow acknowledging that our APIs are
not real, and we can't do components.

So the benefits are (in random order):
being able to detect incompatibilities sooner than later, increase modularity
by making it easier for people to compose individual pieces, not longer
require one big sync'ed release, show that we understand components, force
API to be stable and push the creation of new APIs,etc...

So how to do it:
- run the tool I sent earlier this month
- for each unsatisfied constraint review
the range given and adjust the proposed value depending on the following
cases:
        -
if you use only api from the required plug-in, then specify a range from
the current version up to the next major (for example [3.2.0, 4.0.0)).
This will guarantee that this constraint will be satisfied as long as the
required plug-in does not make a breaking api change.
        -
if you rely on a particular bug fix, then specify a range from the specific
version containing the fix up to the next major (for example [3.1.3, 4.0.0)).
        -
if you use some internals, then specify a range from the specific version
number up to the next minor excluded (for example [3.2.0, 3.3.0)). Basically
here we are trying to be as conservative as possible while still leaving
space for the required plug-in to do bug fix. Of course here there can
be cases where the internal has been changed in the point release, but
restricting ourselves to just one precise version would just be too cumbersome.
Also note that when specifying such a range  you need to enter
a bug report requesting for new API so that this situation does not
occur again in the future.

HTH, 

PaScaL

David M Williams <david_williams@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

06/12/2006 01:11 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, 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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev