Skip to content
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

0.7.0 breaking changes - compatibility tracking issue #319

Open
1 of 7 tasks
federicobond opened this issue Apr 15, 2024 · 8 comments
Open
1 of 7 tasks

0.7.0 breaking changes - compatibility tracking issue #319

federicobond opened this issue Apr 15, 2024 · 8 comments

Comments

@federicobond
Copy link
Member

federicobond commented Apr 15, 2024

With 0.7.0, we are taking a more strict approach to exporting names in our public API. In #306 we began using __all__ inside each package to explicitly declare the names that are exported from it, thus enforcing a canonical import path for each class/function.

Package maintainers: if you were previously importing names from non-canonical locations, you will need to update your imports to point to the canonical ones. Your code should then be able to work with both current and 0.7.0 SDK versions.

We will be releasing 0.7.0 next week probably, and we will be following it up with a 1.0 shortly after 🎉

If you have any other questions, feel free to leave a comment here.

Packages that may need updating

@federicobond
Copy link
Member Author

@nicklasl
Copy link
Member

Thanks for the ping @federicobond 👍

@thomaspoignant
Copy link
Member

@federicobond thanks for the heads up, do you have any example of what tondo by any chance?

@federicobond
Copy link
Member Author

If you are doing things like:

from openfeature.api import EvaluationContext

You will have to change it to point to the canonical location:

from openfeature.evaluation_context import EvaluationContext

Easiest way to check support is running pip install git+https://github.com/open-feature/python-sdk.git@main before your provider test suite.

@beeme1mr
Copy link
Member

@jonathannorris FYI

thomaspoignant added a commit to thomaspoignant/go-feature-flag that referenced this issue Apr 19, 2024
…#319

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>
@thomaspoignant
Copy link
Member

It should be ok for GO Feature Flag, waiting for the SDK to be released to release the new version of the provider.

@thomaspoignant
Copy link
Member

@federicobond do you know when v0.7.0 will be released?

@federicobond
Copy link
Member Author

Thanks for the heads up. I just cut the 0.7.0 release! 🎉

thomaspoignant added a commit to thomaspoignant/go-feature-flag that referenced this issue Apr 30, 2024
* Stop using provider.provider as mentionned in open-feature/python-sdk#319

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>

* Remove usage of status

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>

* remove unused init

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>

---------

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>
keelerm84 added a commit to launchdarkly/openfeature-python-server that referenced this issue May 3, 2024
thomaspoignant added a commit to thomaspoignant/go-feature-flag that referenced this issue Sep 5, 2024
* Stop using provider.provider as mentionned in open-feature/python-sdk#319

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>

* Remove usage of status

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>

* remove unused init

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>

---------

Signed-off-by: Thomas Poignant <thomas.poignant@gofeatureflag.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants