Rename Eclipse features as org.eclipse.embedcdt.*

[ilg-ul]

The discussion was initiated in the mailing list:

• https://www.eclipse.org/lists/embed-cdt-dev/msg00124.html

According to Marc, it should be possible to rename features without affecting existing users:

On 14 Oct 2020, at 01:00, Marc-Andre Laperle malaperle@gmail.com wrote:

Hi! I don’t know if you have done this or seen this before but you can allow installable units to be upgraded to a different id, in p2.inf. At least I know for a fact that it works for features. We have done this in the past a few times in Trace Compass project when things got renamed and moved between projects. Let me know if that’s something that would be useful for embed-cdt in a rename effort that would be transparent to users.

In the p2 wiki there is a solution to use update.matchExp.

An example is in the tracecompass project:

update.matchExp=providedCapabilities.exists(pc | pc.namespace == 'org.eclipse.equinox.p2.iu' && (pc.name == 'org.eclipse.linuxtools.tmf.feature.group' || pc.name == 'org.eclipse.tracecompass.tmf.feature.group'))

[ilg-ul]

I have a functional repo with the new features names:

https://download.eclipse.org/embed-cdt/builds/rename-features/p2/

I installed it on top of the latest embedcpp package from M1, and on top of an older package, and the update was ok.

However I noticed that the Eclipse project names (in .project) need to remain prefixed with ilg.gnumcueclipse.; if I change them to org.eclipse.embedcdt. the update fails. Actually I had to add a separate commit to fix the project names.

Any comments on the project name? Does it have to somehow match the folder name?

The functional commit is on the rename-features branch, the 4e5dd5ca4 commit.

[ilg-ul]

I also renamed the feature projects and the folders.

The test repo is:

• https://download.eclipse.org/embed-cdt/builds/rename-features-folders/p2/

I'm not sure, but it might be possible that the errors I got before while trying to change the project names to org.eclipse.embedcdt. to be caused by the download server, which is very, very slow.

The functional commit is on the rename-features-folders branch, the 54f5833d commit.

@jonahgraham, @ruspl-afed, do you see any problems to merge rename-features-folders?

[ruspl-afed]

It looks more or less correct at first glance, do we plan to have a PR?

[ilg-ul]

do we plan to have a PR

Do you mean a press release? Only if necessary, for now the changes are only cosmetic, no functionality was affected (hopefully).

Otherwise I would announce only for major release, and I feel that changing the plug-in IDs will require a major release.

[ruspl-afed]

I mean GitHub Pull Request :)

Personally I consider the feature identifier change as "breaking change" for integrators, because I always prefer to use upstream on per-feature basis where possible. So on of the option could be to do the bundle identifier change as well and then declare the major release.

[ilg-ul]

I mean GitHub Pull Request :)

Why not merge the rename-feature-folders branch back into develop and then into master?

Is this only to collapse all changes into a single commit?

So on of the option could be to do the bundle identifier change as well and then declare the major release.

Yes, if we change the bundle IDs we have to declare a major release. Otherwise, for the features rename I would not do it yet; integrators could stick to 5.2.1 until 6.x will be ready.

But I still don't know if it is safe to do it for 2020-12.

[ruspl-afed]

Why not merge the rename-feature-folders branch back into develop and then into master?

Usually all the merges to develop/master in GitHub are performed via PRs, it allows to discuss the change set and to check it with CI pipeline.

But I still don't know if it is safe to do it for 2020-12.

AFAIK Embedded CDT doesn't have any consumers inside SimRel except EPP. So, from process perspective such a change can be done before RC1 the latest. However it is better to plan and announce the change like this before the SimRel cycle starts and to apply it for M1.

[ilg-ul]

Usually all the merges to develop/master in GitHub are performed via PRs, it allows to discuss the change set and to check it with CI pipeline.

Ah, right, working mostly alone I'm tempted to take shortcuts, but this is the correct way. See #423.

[ruspl-afed]

Something very strange is going on with comments to this issue: it has stochastic timestamps and placing

[ilg-ul]

I'm temporarily closing this, perhaps we can get rid of the notifications.

[ilg-ul]

a change can be done before RC1 the latest

I found the SimRel schedule, contributions should be frozen by Dec 4th, so we have about one month.

Thus, if you agree, and help me review and merge the current changes, I would like to try to also change the bundle IDs and Java packages to the new names, and go directly to a major v6.x release.

I'd reserve two weeks for this, with two weeks for tests.

In case of problems, of course we can always delay merging the new changes for after 2020-12.

[ilg-ul]

Fixed on 2020-11-01.