RE: [cross-project-issues-dev] RE:Feature Versioning& QualifierSuffixes.

[Kim Moir <Kim_Moir@xxxxxxxxxx>]

Ed, regarding your third point, I have
opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=153978  Europa
discovery site needs to be added to Europa stream builds 

Does anyone know when the Europa update
site will be created?

Kim

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

08/15/2006 01:14 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]        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 (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

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