|Re: [embed-cdt-dev] Renaming features without breaking compatibility?|
We went through such rename during a move from linuxtools project to tracecompass. See for example of a feature supporting both ids
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. 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.
PS: I wasn’t subscribed to the mailing list yet so I can reply to any message in a thread. Hopefully this reply works.
On Oct 30, 2020, at 1:37 AM, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:
Back to the top