[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [embed-cdt-dev] Renaming features without breaking compatibility?
|
> On 2 Nov 2020, at 06:25, Marc-Andre Laperle <malaperle@xxxxxxxxx> wrote:
>
> Hi,
>
> We went through such rename during a move from linuxtools project to tracecompass. See for example of a feature supporting both ids
> https://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/tree/tmf/org.eclipse.tracecompass.tmf/p2.inf?h=stable-4.0
Thank you Marc, I already renamed the features using your solution and it is ok.
> From what I remember (this was years ago now), we only supported *features* being updated to the new ids (I don’t know if you can do the same p2.inf trick for plugins, probably). But we did rename the plugins at the same time along with their packages. Therefore, this was a break of API but not a break of user installations.
I'm working on renaming the plug-ins too.
> Since plugin ids are used as a key to store preferences, I believe we did support loading preferences from both old and new ids for a while. I think some extensions ids or some of their attributes were also kept as is to maximize compatibility (I think they were saved/loaded in the workspace). I guess there is no rule of the thumb for how much effort you should put in maintaining compatibility and not breaking API, but I feel like keep a user installation and workspace working through upgrade is more important.
Agree.
I'll try to add code to get preferences from the old IDs too.
Thank you,
Liviu
