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.

Sign up for GitHub

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

Jump to bottom

Supported Python Versions and Backward Compatibility #330

Closed
s-heppner opened this issue Nov 14, 2024 · 0 comments · Fixed by #332
Closed

Supported Python Versions and Backward Compatibility #330

s-heppner opened this issue Nov 14, 2024 · 0 comments · Fixed by #332
Labels
bug Something isn't working discussion It's not clear yet sdk Something to do with the `sdk` package
Milestone
Release v1.1.1

Comments

@s-heppner
Copy link
Contributor

Currently, we're using datetime.UTC, a constant defined in the built-in datetime module.
However, this constant was only introduced in Python version 3.11, as you can see in the documentation:

We did not catch this, as we most likely programmed the module with Python >= 3.11 and our CI also runs mypy with Python 3.12.

Now, we have two ways forward, in my opinion:

  • Deprecate Python < 3.11 (which I'm against since Python 3.10 has its EoL in 2026-10)
  • Adapt the code to use datetime.timezones.utc instead (which existed beforehand) and furthermore adapt our CI to always test with the minimal supported Python version, as we can reasonably assume that Python is properly backward compatible between minor versions

If we decide for the latter, I'm for deprecating Python 3.8 in the same step, considering it reached its EoL 2024-10-07.
We should also note somehwere that we always support the currently active Python versions (so atm 3.9 - 3.13) and probably need a recurring task that checks the EoL of Python versions (Python 3.9 reaches EoL on 2025-10).
@s-heppner s-heppner changed the title adapter.http: datetime.UTC is only introduced in Python 3.11 Supported Python Versions and Backward Compatibility Nov 14, 2024
@s-heppner s-heppner added bug Something isn't working discussion It's not clear yet labels Nov 14, 2024
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
SDK: Bump required Python version to >= 3.9, Add version CI check
b6c2d47 
This bumps the `requires-python` fiels in the
`pyproject.toml` of the SDK from `">=3.8"` to
`">=3.9"`, due to the fact that Python v3.8
reached EoL on 2024-10-07.

Furthermore, to avoid future backward
compatibility issues in native Python, as well as
to ensure we're always supporting the currently
supported Python versions, we add a CI check
`check-python-versions` that uses two new scripts
in `./etc/scripts` to check:
a) our currently supported Python versions to an
   EoL database
b) that our currently supported Python versions
   defined in the CI match the ones in the
   `pyproject.toml`.

This should ensure that issues like eclipse-basyx#330 are
avoided in the future. (Note that we still need
to fix eclipse-basyx#330 though).
@s-heppner s-heppner mentioned this issue Nov 14, 2024
Merged
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
SDK: Bump required Python version to >= 3.9, Add version CI check
b990d14 
This bumps the `requires-python` fiels in the
`pyproject.toml` of the SDK from `">=3.8"` to
`">=3.9"`, due to the fact that Python v3.8
reached EoL on 2024-10-07.

Furthermore, to avoid future backward
compatibility issues in native Python, as well as
to ensure we're always supporting the currently
supported Python versions, we add a CI check
`check-python-versions` that uses two new scripts
in `./etc/scripts` to check:
a) our currently supported Python versions to an
   EoL database
b) that our currently supported Python versions
   defined in the CI match the ones in the
   `pyproject.toml`.

This should ensure that issues like eclipse-basyx#330 are
avoided in the future. (Note that we still need
to fix eclipse-basyx#330 though).
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
SDK: Bump required Python version to >= 3.9, Add version CI check
6a051f9 
This bumps the `requires-python` fiels in the
`pyproject.toml` of the SDK from `">=3.8"` to
`">=3.9"`, due to the fact that Python v3.8
reached EoL on 2024-10-07.

Furthermore, to avoid future backward
compatibility issues in native Python, as well as
to ensure we're always supporting the currently
supported Python versions, we add a CI check
`check-python-versions` that uses two new scripts
in `./etc/scripts` to check:
a) our currently supported Python versions to an
   EoL database
b) that our currently supported Python versions
   defined in the CI match the ones in the
   `pyproject.toml`.

This should ensure that issues like eclipse-basyx#330 are
avoided in the future. (Note that we still need
to fix eclipse-basyx#330 though).
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
SDK: Bump required Python version to >= 3.9, Add version CI check
ab21d78 
This bumps the `requires-python` fiels in the
`pyproject.toml` of the SDK from `">=3.8"` to
`">=3.9"`, due to the fact that Python v3.8
reached EoL on 2024-10-07.

Furthermore, to avoid future backward
compatibility issues in native Python, as well as
to ensure we're always supporting the currently
supported Python versions, we add a CI check
`check-python-versions` that uses two new scripts
in `./etc/scripts` to check:
a) our currently supported Python versions to an
   EoL database
b) that our currently supported Python versions
   defined in the CI match the ones in the
   `pyproject.toml`.

This should ensure that issues like eclipse-basyx#330 are
avoided in the future. (Note that we still need
to fix eclipse-basyx#330 though).
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
SDK: Bump required Python version to >= 3.9, Add version CI check
b91718f 
This bumps the `requires-python` fiels in the
`pyproject.toml` of the SDK from `">=3.8"` to
`">=3.9"`, due to the fact that Python v3.8
reached EoL on 2024-10-07.

Furthermore, to avoid future backward
compatibility issues in native Python, as well as
to ensure we're always supporting the currently
supported Python versions, we add a CI check
`check-python-versions` that uses two new scripts
in `./etc/scripts` to check:
a) our currently supported Python versions to an
   EoL database
b) that our currently supported Python versions
   defined in the CI match the ones in the
   `pyproject.toml`.

This should ensure that issues like eclipse-basyx#330 are
avoided in the future. (Note that we still need
to fix eclipse-basyx#330 though).
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
SDK: Bump required Python version to >= 3.9, Add version CI check
1e93fa5 
This bumps the `requires-python` fiels in the
`pyproject.toml` of the SDK from `">=3.8"` to
`">=3.9"`, due to the fact that Python v3.8
reached EoL on 2024-10-07.

Furthermore, to avoid future backward
compatibility issues in native Python, as well as
to ensure we're always supporting the currently
supported Python versions, we add a CI check
`check-python-versions` that uses two new scripts
in `./etc/scripts` to check:
a) our currently supported Python versions to an
   EoL database
b) that our currently supported Python versions
   defined in the CI match the ones in the
   `pyproject.toml`.

This should ensure that issues like eclipse-basyx#330 are
avoided in the future. (Note that we still need
to fix eclipse-basyx#330 though).
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
adapter.http: Fix reference to constant from the future
767fc57 
Currently, we're using `datetime.UTC`,
a constant defined in the built-in `datetime`
module.

However, this constant was only introduced in
Python version 3.11, as you can see in the
documentation:

- Does not exist in [datetime Python 3.10]
- Exists in [datetime python 3.11]

We did not catch this, as we most likely
programmed the module with Python >= 3.11 and our
CI also ran `mypy` with Python 3.12.

[datetime Python 3.10]: https://docs.python.org/3.10/library/datetime.html#constants
[datetime python 3.11]: https://docs.python.org/3.11/library/datetime.html#datetime.UTC

Fixes eclipse-basyx#330
s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2024
@s-heppner
adapter.http: Fix reference to constant from the future
e17d7c4 
Currently, we're using `datetime.UTC`,
a constant defined in the built-in `datetime`
module.

However, this constant was only introduced in
Python version 3.11, as you can see in the
documentation:

- Does not exist in [datetime Python 3.10]
- Exists in [datetime python 3.11]

We did not catch this, as we most likely
programmed the module with Python >= 3.11 and our
CI also ran `mypy` with Python 3.12.

[datetime Python 3.10]: https://docs.python.org/3.10/library/datetime.html#constants
[datetime python 3.11]: https://docs.python.org/3.11/library/datetime.html#datetime.UTC

Fixes eclipse-basyx#330
@s-heppner s-heppner added the sdk Something to do with the `sdk` package label Nov 17, 2024
@s-heppner s-heppner added this to the Release v1.1.1 milestone Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working discussion It's not clear yet sdk Something to do with the `sdk` package
Projects
None yet
Milestone
Release v1.1.1
Development

Successfully merging a pull request may close this issue.

SDK: Bump required Python version to >= 3.9, Add version CI check rwth-iat/basyx-python-sdk
1 participant
@s-heppner