Should the "old" terminal get some UI update to indicate such

[jonahgraham]

Open question:

At the moment, depending on what is installed, both the new (eclipse platform) and old (tm) terminal can be present, leading to pretty much identical menu and view entries. The only difference at the moment is the icon.

Should we be adding "deprecated" or other such language to the old one until it can be fully removed from installs?

left is new view right is old view:

cc: @laeubi @merks

[merks]

Yes, I noticed all this with the copilot testing. In some ways it doesn't really matter to the user which one is which as long as either/both work. I don't have an good informed opinions about how best to deal with this. ☹️

[laeubi]

I personally would remove all stuff from CDT repo and if one installs a plugin that can not upgrade let it be the case because we only have two cases:

1. People can upgrade and will do it, as its really little work for the code.
2. If they can not upgrade (for whatever reasons) adding any deprecation will not help in improve/speedup the process.

Copilote sadly not yet has processed with my recommendation to dynamically install either the old or the new one and instead simply install both things now...

[jonahgraham]

I can't remove it from CDT [p2] repo because that would mean dropping TCF/PDT from SimRel too at this point. I don't think we should do that yet, but perhaps in 2025-12. For copilot, I guess its too late for that to join SimRel in 2025-09 anyway.

I guess for now we just have a (hopefully) temporary state where people are exposed to both. I am using this issue to document that fact so that I can point people back to it and any further advice that is needed can be put here too.

[laeubi]

I can't remove it from CDT [p2] repo because that would mean dropping TCF/PDT from SimRel too at this point.

I don't see a reason why TCF/PDT can not use an old CDT Updatesite with the terminal.tm stuff from there and must consume it from CDT latest.

I don't think we should do that yet, but perhaps in 2025-12

Yes I also thing for 2025-09 its really to late to do anything here.

[jonahgraham]

I don't see a reason why TCF/PDT can not use an old CDT Updatesite with the terminal.tm stuff from there and must consume it from CDT latest.

Do you suggest that we contribute old CDT update site and latest CDT update site to SimRel? That is what I had been avoiding by making CDT update site complete and self-contained. But if you and @merks don't see a problem with that, I can remove old terminal from CDT update site, but it will still be in SimRel.

[merks]

I think it would be better for CDT to have a "clean" site with the things CDT needs for its own release. If anything else needs "older stuff" then you could contribute an older site for that purpose. Please keep in mind that when you add a site, if you specify nothing at all to come from it, the aggregator will include everything from that site. So if you add a site for "older stuff" be sure to specify one thing to aggregate from that site; anything else that needed will just be pulled in via normal requirements so pick something that's needed elsewhere.

[laeubi]

Do you suggest that we contribute old CDT update site and latest CDT update site to SimRel? That is what I had been avoiding by making CDT update site complete and self-contained.

In fact I would suggest that TCF/PDT

1. Add whatever CDT release seems suitable in their target configuration
2. Include the legacy terminal stuff in their own update site
3. Contribute that to SimRel (so then it becomes part of simrel implicitly)

Because it always is/was bad to rely on someone else to contribute stuff you need (let it be Platform or CDT) for "third party content" (what I would say the legacy terminal bundles are now). But of course @merks is the SimRel expert and might have other recommendations.

This is also the reason why I strongly believe that the new way of building "slim sites" that are still complete is something that any project should use, that way all content is always there but nothing is distribute duplicated. And if one thing goes away from the site it is automatically provided by some other means.

[merks]

Of course both projects should use the new terminal implementation. I would not be happy to see them using the "legacy" bundles long term. For the short term, that's not so nice but not unspeakably horrible.

---

TCF has not updated their contribution for a long time and nothing in SimRel depends on it. I think nothing in EPP/CDT depends on it either. So it is possible to simply disable the contribution pending action from the project. I've opened the following issue with a back reference to this issue:

https://gitlab.eclipse.org/eclipse/tcf/tcf/-/issues/108

---

PDT is a more difficult problem because the @zulus appears to be missing in action for far too long. So, temporarily we could add an older CDT repository there, but long term we need action on this issue as well as on

eclipse-dltk/dltk.core#5

The only other alternative is removing it from SimRel and stop building the PHP package. Which would be unfortunate because quite some users love it and much effort has been invested here.

I could create a call-to-action notification in the PHP package for the coming release cycle and hope that someone loves this enough to help support it.

[laeubi]

@merks as I'm using the PHP package from time to time I could probably help with bring it up-to date but of course it requires a functional project team that responds to pull requests.