[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Supporting nightly updates for previous release
|
On 05/25/2010 03:15 PM, Alexander Kurtakov wrote:
I was briefly discussing this with Andrew, but thought I would pose the
idea here for comment.
At present, we are building nightly updates from trunk. For the most
part, this isn't a problem. However, when we make any changes that
require latest versions of underlying plugins (e.g. we use a new
platform interface or we switch to requiring latest CDT, Mylyn, etc..),
then nightly updates may no longer apply to the previous release as they
don't meet prereqs.
I would like to propose that we support multiple versions of a plugin on
the update site where necessary so that the previous release of Eclipse
can still acquire nightly updates.
For example, there is a new way of getting a CDT translation unit that
doesn't violate API annotations and Autotools should use this new API.
It only exists in CDT 7 which means that I will have to branch Autotools
into a Galileo maintenance branch once I make the fix in trunk. If I
make any fixes to Autotools after that, there is no current mechanism
for getting them to end-users via the normal nightly update system.
Ideally I would like to have it set up so there is one nightly update
site that contains latest fixes for either Galileo or Helios, but I
think it would also be ok to just set up a separate site for Galileo if
mixing multiple levels of plugins is not worth the effort.
Comments?
With the number of contributions I doubt we will be able to keep things
working for two platform releases. (I'm sure I can not promise that for the
RPM editor and stubby).
Don't think of it as a promise. I think there will be a number of users
who won't automatically move to the latest Eclipse release as soon as it
comes out. For example, they might have some plugin issues which
precludes them from moving (i.e. bugs not yet dealt with) or they might
just be lazy and happy with their current set-up.
The idea would be that you would only branch your code once your plugin
no longer supports the previous release. Only then would you attempt at
your own discretion to apply patches to both trunk and branch. It is
your choice of what constitutes a bug worthy of multiple maintenance and
what kind of effort you are willing to do if it does not apply cleanly
without modification.
For example, if the RPM editor had a security bug, you would want the
next update to replace the offending code. With the current mechanism,
you have no way of doing that if the current trunk code prereqs Helios
and the user hasn't yet migrated.
Anyway this may benefit some of the subprojects but others should be allowed to
make use of the new APIs without taking care of backward compatibilities once
Helios is out.
Alex
-- Jeff J.
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
