Skip to content

Update migration strategy #2156

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

Merged
merged 1 commit into from
Nov 1, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 5 additions & 22 deletions MIGRATION_TO_CORE.md
Original file line number Diff line number Diff line change
@@ -1,28 +1,11 @@
# Migration From TF-Addons To TensorFlow Core

### In-Progress & Previous Migrations:
https://github.com/tensorflow/addons/projects/2/

### Process
1. Create an issue in TensorFlow Addons for a candidate that you think should be
migrated.
2. The SIG will evaluate the request and add it to the `Potential Candidates` section
of our GitHub project.
3. If it's agreed that a migration makes sense, an RFC needs to be written to discuss
the move with a larger community audience.
* Additions which subclass Keras APIs should submit their migration proposals to
[Keras Governance](https://github.com/keras-team/governance)
* Other additions should submit their migration proposals to
[TensorFlow Community](https://github.com/tensorflow/community)
4. If approved, a pull request must move the addition along with proper tests.
5. After merging, the addition will be replaced with an alias to the core function
if possible.
6. If an alias is not possible (e.g. large parameter changes), then a deprecation
warning will be added and eventual removed after 2 releases.
# Migration From TF-Addons To TensorFlow Core / Keras

**Given the challenges of external SIG coordinating with internal roadmaps, a new
process has been put in place for the core TF and Keras teams to handle migration
and deprecation of Addons components. If you believe there is a strong candidate for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the real problem here is about expecting a deprecation PR.
I think it is plausible to expect this if we have a "real" migration approach but instead it will be very hard if we have a duplicative process in the "ecosystem".
When you start to duplicate something it is hard to expect that you will care about a deprecation cause probably in the duplication act implicitly you didn't care about checking in the ecosystem.
It is not totally correlated cause there could be real cases when you are constrained to reinvent the wheel but I suppose there is a very strong relationship between the duplication behaviour and the lack of deprecation activities.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to make a pratical use case:
#2004 (comment)

migration please post an issue and we'll escalate it to the respective team members.**

### Criteria for Migration
* The addition is widely used throughout the community
* The addition is unlikely to have API changes as time progresses
* The addition is well written / tested