Decide and document a policy for supported Python versions

[da4089]

We should decide which Python versions to support (and test) and document them.

In particular, I guess, we should decide whether to support Python 2.x still.

[return42]

In particular, I guess, we should decide whether to support Python 2.x still.

Really a need for py2? .. py2.7 EOL 2020-01-01 .. are there LTS distros who still use py2.7 and worth to considered?

[da4089]

Personally, I'd suggest 3.8 to 3.12, given they're the supported releases at python.org, but I realize some people might have constraints from eg. LTS releases to earlier versions.

https://devguide.python.org/versions/

[return42]

I'd suggest 3.8 to 3.12, given they're the supported releases at python.org

consent .. further we should only support Python versions for which we run a test in the CI / BTW you can drop 3.7 from CI :)

vobject/.github/workflows/test.yml

Line 8 in e00b430

python-version: ['3.7', '3.8', '3.9', '3.10', '3.11', '3.12']

[da4089]

This PR/issue looks like it's a 2.x problem, so if we decide to support 2.x, it'll need to be merged: skarim#161

[return42]

It needed to be merged even we do not support py2 .. here and in other places we use it:

vobject/vobject/base.py

Line 9 in e00b430

import six

Tidy up the usage of six should be done in a PR later ...

[da4089]

@return42, you're right. I've merged this fix.

[zeehio]

This PR/issue looks like it's a 2.x problem, so if we decide to support 2.x, it'll need to be merged: eventable#161

Thank you all for forking and maintaining object. I am a user of "radicale", a carddav server, and vobject is one of its dependencies. I wrote that PR because I created a virtual environment to run radicale and the environment was unable to run radicale unless I manually installed six as well.

I do not need or want support for python 2.x. I am very happy to see vobject supported. Whatever you decide is good for me, but the strategy of supporting non-EOL python versions seems logical to me.

Are you going to apply for uploading to pypi under the same original name? If you plan to preserve backwards compatibility I guess keeping the name would make a lot of sense. I just learnt about pep 0541:

https://peps.python.org/pep-0541/#continued-maintenance-of-an-abandoned-project

Good luck on this fork and I hope we can all celebrate many vobject anniversaries from now on!

[da4089]

Looking at Red Hat Enterprise Linux Releases

Let me preface this by saying I'm not entirely convinced that the version of Python installed by default on a long-term support Linux release should dictate what versions vObject should support, but ... it's certainly a factor to consider in making that decision.

So:

• RHEL5 support ended 2017/03/31 (paid ELS ended 2020/11/30)
• RHEL6 support ended 2018/12/31 (paid ELS ends 2024/06/30)
• RHEL7 support ends 2024/06/30 (paid ELS ends 2028/06/30)
• RHEL8 support ends 2029/05/31 (paid ELS ends 2032/05/31)
• RHEL9 support ends 2032/05/31 (paid ELS ends 2035/05/31)

So, I think RHEL7 is the earliest Red Hat release we should consider supporting, but given general maintenance for it ends in June this year, I'd be kinda tempted to instead aim for RHEL8 as a reasonable minimum.

That ends up working out too, because RHEL7 is the last RHEL where Python 2.x is the default system interpreter.

• In RHEL7, Python 2.7 is the default system version.
• In RHEL8, Python 3.6 is the default system version.
• In RHEL9, Python 3.9 is the default system version.

In all cases, Red Hat makes later versions available. I personally think that's a more reasonable thing to rely on, rather than the system (they call it "platform") Python, because otherwise you'd still be using eg. on RHEL8, Python 3.6 in 2029, 8 years after the upstream EOL.

For RHEL8, it looks like

• Python 3.8 was added in May 2020, and removed in May 2023
• Python 3.9 was added in May 2021, and will be removed in May 2024
• Python 3.11 was added in May 2023, and will be removed in May 2026

For RHEL9, it looks like

• Python 3.11 was added in May 2023, and will be removed in May 2026

References:

• https://devguide.python.org/versions/
• https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8-3
• https://developers.redhat.com/blog/2018/08/13/install-python3-rhel
• https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle

[da4089]

Looking at Ubuntu LTS Releases

Again, I'm not sure that our supported versions should rely on what Ubuntu does, but it's useful information to consider in making the decision.

Lifecycle dates:

• 14.04 support ended 2019/04 (paid Pro support ends 2024/04)
• 16.04 support ended 2021/04 (paid Pro support ends 2026/04)
• 18.04 support ended 2023/04 (paid Pro support ends 2028/04)
• 20.04 support ends 2025/04 (paid Pro support ends 2030/04)
• 22.04 support ends 2027/04 (paid Pro support ends 2032/04)

Following the pattern I suggested for Red Hat, I think we should look only at the general support dates, thus considering only 20.04 and 22.04.

• In 20.04, Python 3.8.2 is the default system version.
• In 22.04, Python 3.10.4 is the default system version.

So ... that's looking like Python 3.8 is a decent minimum for both Ubuntu and Red Hat.

References

• https://ubuntu.com/about/release-cycle
• https://askubuntu.com/questions/1232812/whats-the-default-python-version-in-ubuntu-20-04
• https://askubuntu.com/questions/1451071/whats-the-default-python-version-in-ubuntu-22-04

[return42]

So I think that's probably a good minimum to consider targeting for Red Hat LTS systems.

.. and for niche cases there are other options like asdf-vm, docker or LXC.

[da4089]

Are you going to apply for uploading to pypi under the same original name? If you plan to preserve backwards compatibility I guess keeping the name would make a lot of sense. I just learnt about pep 0541:

https://peps.python.org/pep-0541/#continued-maintenance-of-an-abandoned-project

I am hoping (though it's likely futile) that we'll be able to arrange a handover of the PyPI access. I have attempted to contact all three of the listed maintainers. I heard back from one, who only said they had nothing to do with it any more.

So, it might be possible to have new maintainers added so we can push a release, or perhaps the one responsive maintainer might decide to volunteer to make PyPI releases using this repository, or (as a last resort) we will attempt the PyPI abandoned projects process.

I haven't started down that path yet: I think it's important to show some "liveness" of the project, and ideally contributions from more than one person, before really claiming to be a successor. Without having really thought it through, maybe sometime in March would be reasonable -- if nothing else, we should have a bunch of fixes ready to release by then.

Thanks for your support!

[return42]

before really claiming to be a successor ... -- if nothing else, we should have a bunch of fixes ready to release by then.
So, it might be possible to have new maintainers added so we can push a release,

If this cannot be clarified with the old pypy rights holders, then this project can also be published on pypi under a different name (e.g. vobjectnx) .. so other projects using vobject can decide to switch to the next generation .. just by modifying their requirements.

[da4089]

Looking at SLES Releases

• SLES 11 general support ended 2019/03/31 (LTSS support ended 2022/03/31)
• SLES 12 general support ends 2024/10/31 (LTSS support ends 2027/10/31)
• SLES 15 general support ends 2028/07/31 (LTSS support ends 2031/07/31)

So, again looking at general support dates, we could support SLES12 until October, after which only SLES15 is still active.

SuSE appears to add (and remove) Python versions in service packs.

• In SLES 12, Python 3.4 was the default system version. SP5 added Python 3.6.
• In SLES 15, Python 3.6 was the default system version. SP3 added Python 3.9, SP4 added Python 3.10, and SP5 added Python 3.11.

So, if we were to consider SLES 12, we'd have a minimum of Python 3.4 available, and Python 3.6 if the latest service pack is installed. SLES 15 with service packs installed has Python 3.11. It's not clear to me if SLES operators would install service packs as a standard thing.

It's also not clear to me how important SLES is in 2024.

References

• https://www.suse.com/lifecycle/#product-suse-linux-enterprise-server
• https://www.suse.com/releasenotes/index.html

[da4089]

I'm going to think about this a little more, but right now, I'm considering a policy of:

vObject will support the CPython lifecycle, plus one year

That would mean that we support Python 3.8 until October 2025, and then move the minimum to 3.9 until October 2026, then 3.10 until October 2027, and so on.

This aligns with Ubuntu 20.04 (with 3.8) which is EOL in April 2025. RHEL now basically has rolling 3 year support (ending before the upstream EOL). SLES SP5 has 3.11, so it's ok until October 2027.

How's that suit everyone?

[rixx]

Honestly, I feel like it's fine to support currently-supported (non-EOL) Python versions, as long as you make one release prior to ending support of earlier versions. This way, people stuck on older Python versions can still install a version compatible with their version, without you having to keep an increased support window in mind.

(Also, thank you for picking up this project – just spotted this when my ages-old PR got merged. Yay for support for *gasp* half-hour timezone offsets.)

[da4089]

It looks like Radicale supports Python 3.7, and I'm pretty inclined to support their usage.

As it turns out though, that actually fits the policy statement above: 3.7 EOL was 2023/06/27, and so vObject should support it until 2024/06/27 -- roughly 4 months from today.

[da4089]

I'm going to

• document the "python.org + 1 year" policy in the soon-to-be-created Programmer's Guide
• create a shipping-0.9 branch in Git, to which we'll apply any urgent/important patches that we need to release to support users
• try to get a 0.9.8 release tagged and pushed to PyPI from the shipping-0.9 branch
• change master to Python 3.7 or later, and begin to remove 2.x stuff and take advantage of 3.7+ features
• work towards a 1.0 release in master

Thanks for the feedback everyone! Roll on Python3!

[rixx]

I haven't started down that path yet: I think it's important to show some "liveness" of the project, and ideally contributions from more than one person, before really claiming to be a successor. Without having really thought it through, maybe sometime in March would be reasonable -- if nothing else, we should have a bunch of fixes ready to release by then.

That's very sensible – is there any way of getting notified when there's a PyPI release? I'm fairly eager to have a maintained version of vobject in several of my projects – no hurry at all, I'm very glad to see you taking this up, just don't want to miss the release because I forget to periodically check the repository etc.

[return42]

It looks like Radicale supports Python 3.7, and I'm pretty inclined to support their usage.

As it turns out though, that actually fits the policy statement above: 3.7 EOL was 2023/06/27, and so vObject should support it until 2024/06/27 -- roughly 4 months from today.

@pbiering @da4089 : From personal experience, I know how difficult it is to support Python versions that have already reached their EOL. It massively inhibits your own development and is a source of errors. In projects like these, where resources are severely limited and the user group with such a need has alternatives (asdf, container ..), you should not try to support Python versions after official EOL.

Related: Kozea/Radicale#1329 (comment)

[pbiering]

Lifecycles of Phython are a still not really matching long running stable services on production servers with LTS Linux as of today.

I've analyzed current Python requirements and LTS Linux (at least Red Hat) for Radicale

• upcoming 3.1.9 has already dropped support for Phython 3.6
• 3.2.x series will drop testing for Python 3.7
• Python 3.8 support has to stay for EL8 until uplifted to Python 3.9 (which is also available in appstream/epel)
• Python 3.9 support has to stay until EOSL of EL9 is reached

Have not screened Ubuntu LTS versions so far, potentially this can also have some impact.

See also:
https://github.com/Kozea/Radicale/wiki

Problematic on LTS Linux is also dependency to other packages, which partially still not build for optional usable Phyton versions and therefore have to be bundled with "radicale" :-(

Which results on EL8 already by bundling "dateutil" + "defusedxml" + "passlib" + "setuptools_scm" (beside "vobject") because they are only available for Python 3.6 (which is the main Python version on EL8), but not on EPEL for Python 3.8.

Created now a poll: Kozea/Radicale#1408

[da4089]

I haven't started down that path yet: I think it's important to show some "liveness" of the project, and ideally contributions from more than one person, before really claiming to be a successor. Without having really thought it through, maybe sometime in March would be reasonable -- if nothing else, we should have a bunch of fixes ready to release by then.

That's very sensible – is there any way of getting notified when there's a PyPI release? I'm fairly eager to have a maintained version of vobject in several of my projects – no hurry at all, I'm very glad to see you taking this up, just don't want to miss the release because I forget to periodically check the repository etc.

@rixx, that seems like a reasonable thing to want. I'm not sure how best to implement it. I will investigate.

[rixx]

@da4089 Please don't worry about this – I was making that request before the first new vobject release was made, back when it wasn't clear if there would be a new PyPI project, or if the current project was handed over. Now that it seems like the releases will take place on PyPI, all the usual notification tools (watching PyPI / RSS feeds for GitHub and PyPI / dependabot) should work as expected, so no need for anything custom, I think!