Addons: Clarifying the CI and supported versions of tensorflow/python

[gabrieldemarmiesse]

Hello all,

I'm trying to see how we can improve the developers experience in tensorflow/addons. I'm confused about a few things and I hope maintainers can answer my questions to help me make addons better :)

• Can we add a new row in the linux build matrix in the README about the master branch? Like what TF/Python/Cuda version do we target? It's currently unclear from the CI.

• Do we sync tf addons releases on TF releases? Do we want to?

• Do we want our SO files to work with tensorflow-cpu ? Currently pure Python objects work well with it.

• Is it necessary to use tf nightly in the unit tests locally and in the CI? Can we use the latest stable version? Usually in the CI, a best practice is to pin the dependencies' versions to avoid having the master branch build breaking suddently. We can then do the upgrade of the dependencies in pull requests which confines the upgrade issues in separate branches and can be worked on without being in a rush.

• In the CI, do we build against the most recent version of python that we support, or the oldest? I believe it would be good to have both to ensure forward and backward compatibility.

Thanks for answering my questions! :)

[seanpmorgan]

• Can we add a new row in the linux build matrix in the README about the master branch? Like what TF/Python/Cuda version do we target? It's currently unclear from the CI.

Yes I think that's a good idea.

• Do we sync tf addons releases on TF releases? Do we want to?

No, but in the past we've used new features (keras serialization) so that required us to wait until TF2.1 release. TF-Core is switching to quarterly releases and I think a faster cadence makes sense for Addons.

• Do we want our SO files to work with tensorflow-cpu ? Currently pure Python objects work well with it.

Yes. From that error in the other issue I believe we may have to re-evaluate our CUDA linking. Certainly worth working through.

• Is it necessary to use tf nightly in the unit tests locally and in the CI? Can we use the latest stable version? Usually in the CI, a best practice is to pin the dependencies' versions to avoid having the master branch build breaking suddently. We can then do the upgrade of the dependencies in pull requests which confines the upgrade issues in separate branches and can be worked on without being in a rush.

So historically we had breaks every couple of days when TF2.0 was in beta. That was a primary reason for the nightly tests against tf-nightly so we could start working through them. Now that everything is more stable I think this is a viable strategy. Will think on it more when I get back. @tensorflow/sig-addons-maintainers thoughts?

• In the CI, do we build against the most recent version of python that we support, or the oldest? I believe it would be good to have both to ensure forward and backward compatibility.

Just a single version right now. I think oldest and newest is a good idea though.

[gabrieldemarmiesse]

Thanks a lot @seanpmorgan for clarifying all that!

[seanpmorgan]

Closing this as I believe these have been addressed.