You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current code base is set under the com.o19s.es package structure, owing to its origin as an Elasticsearch plugin. With this fork specifically for OpenSearch it makes sense to keep the package names similar.
What users have asked for this feature?
This is focused only on developers. @epugh is one example.
What problems are you trying to solve?
Avoid confusion about what search engine the code is meant to work with.
What is the developer experience going to be?
One downside would be that diffing code between the Elasticsearch fork and this one will be harder. Another might be that users who build their own version of the plugin, with their own code additions, will need to do a bunch of renaming.
However, simplifying the package namespace should have a positive impact overall.
Are there any security considerations?
None.
Are there any breaking changes to the API
No, none of the user-facing APIs will change.
What is the user experience going to be?
The user will experience no change
Are there breaking changes to the User Experience?
No.
Why should it be built? Any reason not to?
This is almost purely for the developer experience. It's confusing for developers to have this odd package structure.
What will it take to execute?
This would be a fairly simple refactoring. IntilliJ could probably do it automatically.
Any remaining open questions?
No.
The text was updated successfully, but these errors were encountered:
[Search Triage] Thanks for filing it! @sstults / Eric Pugh - if you working on this for 2.19 - please ensure there are no downstream breaking changes with this refactoring!
What/Why
What are you proposing?
The current code base is set under the com.o19s.es package structure, owing to its origin as an Elasticsearch plugin. With this fork specifically for OpenSearch it makes sense to keep the package names similar.
What users have asked for this feature?
This is focused only on developers. @epugh is one example.
What problems are you trying to solve?
Avoid confusion about what search engine the code is meant to work with.
What is the developer experience going to be?
One downside would be that diffing code between the Elasticsearch fork and this one will be harder. Another might be that users who build their own version of the plugin, with their own code additions, will need to do a bunch of renaming.
However, simplifying the package namespace should have a positive impact overall.
Are there any security considerations?
None.
Are there any breaking changes to the API
No, none of the user-facing APIs will change.
What is the user experience going to be?
The user will experience no change
Are there breaking changes to the User Experience?
No.
Why should it be built? Any reason not to?
This is almost purely for the developer experience. It's confusing for developers to have this odd package structure.
What will it take to execute?
This would be a fairly simple refactoring. IntilliJ could probably do it automatically.
Any remaining open questions?
No.
The text was updated successfully, but these errors were encountered: