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