Skip to main content

[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>>

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Monday, August 14, 2006 4:22 PM
To: Cross project issues
Subject: RE: [cross-project-issues-dev] RE:Feature Versioning& QualifierSuffixes.

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 (  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.



Back to the top