-
Notifications
You must be signed in to change notification settings - Fork 344
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
Refactor pipeline implementation to use common pattern for file naming #3160
base: main
Are you sure you want to change the base?
Conversation
e514029
to
d28b77e
Compare
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.
These name changes seem a bit arbitrary given there was already a "common pattern" but I also prefer the adjective to precede the noun so have no immediate issues.
That said, this will break anyone that has written code against these modules, either via subclasses or otherwise, so is this slated for a major release? Should "deprecation shims" be introduced that essentially alias the old names to the new names?
Signed-off-by: Fellipe Resende <[email protected]>
Signed-off-by: Fellipe Resende <[email protected]>
Signed-off-by: Fellipe Resende <[email protected]>
@kevin-bates agreed, it is a very major change. Definitely in favor of deprecation shims. |
I was the one suggesting @fresende to work on these updates. @kevin-bates I was under the impression that we were moving towards Elyra 4.0 where breaking changes were welcomed. Also, I would say this would have very little impact on users, as these are internal APIs and mostly only used by folks that are extending Elyra with new processors. @shalberd is this your case? |
Ok. That should be noted somewhere in this PR. I figured this was just another PR. If a 4.0 release is near, folks should be informed that this kind of breaking change is coming so they can, for now, cap Elyra < 4. This just seems like an itch that wanted to be scratched and nothing more. Yes, the names flow a bit better but is it worth the heartburn? The PR stats using a "common pattern", but there was already a common pattern in place, just with the adjectives following the nouns rather than the other way.
True, although I think is is more of an issue with anyone subclassing existing processors. Folks creating their own (independent) processors should not run into issues. I'd love to hear @shalberd's thoughts as well. Since I really don't have the bandwidth to spend time on this project, I think making a best effort at communicating that the next major release will break folks extending the existing processor packages is sufficient, and you get your itch scratched at the same time. 😄 |
I am on vacation so briefly put, I also think it is more of an issue with a new processor subclassing existing ones. For Airflow 2.0 replacing long gone Airflow 1, how shall I proceed? We have the guidelines and hints for Elyra 4 aleady? |
Some discussions in #2550 |
@fresende Could you please update/rebase this one? |
What changes were proposed in this pull request?
Refactor pipeline implementation to use common pattern for file naming
How was this pull request tested?
By existing pyTests
Developer's Certificate of Origin 1.1