-
Couldn't load subscription status.
- Fork 147
Rename eclipse.tm.terminal > eclipse.terminal #1979
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Test Results 1 947 files ±0 1 947 suites ±0 1h 29m 10s ⏱️ - 2m 21s Results for commit 65ed9ea. ± Comparison against base commit 731e745. This pull request removes 336 and adds 336 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
| org.eclipse.terminal.internal.emulator;x-internal:=true, | ||
| org.eclipse.terminal.internal.model;x-internal:=true, | ||
| org.eclipse.terminal.internal.preferences, | ||
| org.eclipse.terminal.internal.provisional.api, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the before naming of these packages isn't great - but many of these packages with "internal" in their name are API (no x-internal tag). This means that consumers of this API now have to adapt.
For example in other parts of CDT we use these packages.
These packages were explicitly API, see for example eclipse-cdt/cdt@3d2cdcc
Therefore, I don't think we can rename these packages without even more coordination with CDT (and possibly other clients - but honestly I don't know if there are any)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PS If I said something earlier that implied approving of this change then I apologize for my confusion over what was being renamed. I am ok to rename the features, and I would be ok to rename the bundles/packages in alignment with other projects (mostly CDT)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jonahgraham yes consumers need to adapt when migrating to the new namespace, I also think we should make things that are not really "internal" should be made proper API now. I Plan to do that for the provisional.api packages as a next step.
FYI @merks @akurtakov @jonahgraham