[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] RE:Feature Versioning& QualifierSuffixes.
|
[It's interesting to see the wierd transformations of the
subject line - I wonder what causes that. -Ed]
I thought it was agreed a while ago to have a 'loose'
option that would let the user in this case override the strict upper version
limit specified by the feature or plug-in and try running it anyway. I expected
the Install/Update preference for equivalent vs. compatible to possibly do that
but it doesn't.
When I get a new version of Firefox (which is often, since
they keep pushing out security fix versions or betas), sometimes it breaks
existing plug-ins. Somehow Firefox knows whether the plug-in is or isn't
compatible with the new Firefox. But there's almost always an option to install
an updated version of the plug-in that works with the new Firefox. I
haven't studied Firefox packaging and installs enough to know how they do that,
does anybody know? From and end-user point of view, the Firefox model works
really well and it would be nice if Eclipse could work the same
way.
Regarding whether or not the Callisto discovery site is
recommended for 3.3, I'd like to point out that site name and URL is currently
hard coded in 3.3M1. So is the Eclipse Updates site, which also has a copy of
WTP that can't be installed in 3.3. Note I'm not trying to pick on WTP, but
that's just the first one I tried because I needed an XML editor.
Anybody who reads the "Eclipse 3.3Mx released" type of posts on
EclipseZone or wherever and tries to install and use it (which you want to
encourage, right?) is likely to run into this.
--Ed B
<<Bad Wolf>>
As Tim and others have suggested, in
an ideal world this is fairly straight-forward. API providers would never
introduce breaking changes, and thus never increment their major number.
Thus downstream plugins could use an "x+1.0.0" upper bound as described by
Ed, and it would never require changing. The platform will never "move to 4.0" -
there may be a release called 4.0, and there may be the odd plugin that
eventually require breaking changes and increment their major version, but
individual plugins will never "en masse" change their major version number.
Since breaking changes will be a rare event, and will almost always
require some migration work for clients anyway, the task of bumping up the upper
bound on the version range shouldn't be too onerous. I agree with Ed that there is a risk of the lower bound
becoming stale, but I would argue that a stale value is not useless - it
steadily degrades in accuracy but still marks a known point where the plugin was
known to be working (which is much better than the state of the world before we
started using version dependencies). There has been some discussion of
tooling to help flag incorrect lower bounds but nothing has come of it yet
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=121572). On the other hand,
auto-generating the lower bound in the build is also a reasonable approach, but
will exclude some possible configurations that likely still work.
On the subject of "tight vs. loose" in the
case of plugins that rely on internals, the base platform opted for "loose". API
violations are considered the exception rather than the norm, and plugins for
the most part keep working across minor releases even if they have the
occasional API violation. However, as Tim says, this could cause failure
in random and unexpected ways - but blame for such failures can correctly be
laid on the API violation rather than on poor choice of version range. I'm
not saying this is the "right" answer, because it's really a trade-off between
the risk of failure and the pain of constantly having to increment version
ranges. As someone who can no longer easily use WTP because I'm on the bleeding
edge of the platform, I suggest you also keep in mind the early adopter
community who jump to each new milestone and are so valuable in providing bug
reports and other feedback. john