[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipse-dev] Planning Meeting Notes - Nov 12, 2003
- From: Dejan Glozic <dejan@xxxxxxxxxx>
- Date: Thu, 13 Nov 2003 07:48:01 -0500
- Delivered-to: firstname.lastname@example.org
Update team is currently making a full sweep through the Update Core APIs
and many things will change as a result. I suggest that we take this
discussion to platform-update-dev for the benefit of the general Eclipse
community :-). We can answer how these requirements may be satisfied
without downsides using the new Update capabilities.
Dejan Glozic, Ph.D.
Manager, Eclipse Platform Components
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4854
Sent by: <eclipse-dev@xxxxxxxxxxx>
Re: [eclipse-dev] Planning Meeting
11/13/2003 05:11 Notes - Nov 12, 2003
Please respond to
This might be ok if the API discipline and quality control of these
incremental component releases were the same as for major/minor releases of
Eclipse, but do you really have the infrastructure to support this?
It would be a nightmare for third-party plug-in writers if API (e.g., some
feature not used within Eclipse, itself) subtly shifted or was broken in
these incrementals, since few of them have the resources to track and test
with n ongoing streams of development.
----- Original Message -----
From: "Jeff Duska" <Jeff.Duska@xxxxxxxx>
Sent: Wednesday, November 12, 2003 10:18 AM
Subject: Re: [eclipse-dev] Planning Meeting Notes - Nov 12, 2003
> Discussion Topics:
> >- Using features to provide finer grain upgrade paths for selected
> >components of the SDK? For example, it could make sense to have CVS as a
> >separate feature and allow us to release upgrades, major bug fixes,
> >outside the SDK release schedule. Comments?
> I think this would be excellent idea. I think CVS, Ant, SWT are all
> components that might have important bug fixes or enhancements that
> should/could need to be upgraded before a new stable release of Eclipse
> it completed. It would also be helpful for developers that use Eclipse
> as platform to have this functionality at their disposal. For example,
> a plug-in might only need a new version of CVS plug-in or etc. not a
> whole new release of Eclipse. This would help them upgrade. I'm also
> thinking that this might useful, if there are ever any security issues
> found within the Eclipse platform. Instead of having to reinstall a new
> version of Eclipse, they would be able to just use a small patch to the
> affected area.
> On the downside, this will be more complex for the user. Now, the user
> only worries about what version of Eclipse she might be running. If this
> goes too far the user will have to worry about what version of each
> component they are running.
> Jeff Duska
> eclipse-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit