# Handling stale Python version classifiers for low churn projects **URL:** \ **Category:** Packaging\ **Tags:** help\ **Created:** [October 3, 2024, 4:02pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537 "2024-10-03T16:02:44Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![bwoodsend](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bwoodsend/32/4027_2.png) [@bwoodsend](https://discuss.python.org/u/bwoodsend)\ **Post date:** [October 3, 2024, 4:02pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/1 "2024-10-03T16:02:44Z")
The recent discussions mentioning the `Programming Language :: Python :: 3.xx` trove classifiers (mostly from the [who supports 3.13 yet? conversation](https://discuss.python.org/t/adoption-of-new-python-in-pypi-packages-longer-rc-periods/66158) where people are relying on them to gather machine readable data) got me looking at my own packages. About half of them are small, narrowly scoped, low maintenance projects which have worked out of the box for the last few new Python versions and I haven’t had to release them for years so, despite being tested against 3.13-dev, they only allegedly support up to Python 3.9 or up to 3.10 according to the classifiers that PyPI is displaying. It’s a minor issue but I imagine that it happens to quite a lot of projects/maintainers. I think I have 3 options here: 1. Ignore the minor piece of misinformation and hope no one misinterprets it as a sign that the projects are abandoned 2. Do an otherwise pointless release just to get wheels with the updated classifiers onto PyPI 3. Stop using the Python version classifiers for low churn projects since they’re wrong more often than they’re right I got halfway through doing option 3 before I decided to hear what other people think first? What (if anything) do people use those classifiers for and how would they be affected by either option 1 or option 3? ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [October 3, 2024, 5:58pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/2 "2024-10-03T17:58:09Z")
I don’t think I do this myself, but if you expect your project will be compatible with all Python 3 versions, just put the `Programming Language :: Python :: 3` classifier and don’t get any more specific? ---
**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\ **Post date:** [October 3, 2024, 6:20pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/3 "2024-10-03T18:20:17Z")
It’d be nice if the trove classifier was used to mean something like “minimum supported version”, indicating what syntax is needed (e.g. I’m using `match` statements, or `:=` operators, or whatever) and higher versions should be supported. If a new Python version arrives and something in the old package is deprecated, then there needs to be a new release anyway, and the classifier can be updated. I don’t think there’s a way to just adopt that convention, though–it’d probably require removing these classifiers and adding a new one. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [October 3, 2024, 9:17pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/4 "2024-10-03T21:17:11Z")
> [@jamestwebber](#): > > It’d be nice if the trove classifier was used to mean something like “minimum supported version” `requires-python` explicitly covers that use case, though, as the support floor. ---
**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\ **Post date:** [October 3, 2024, 9:38pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/5 "2024-10-03T21:38:14Z")
Oh yeah 🤦‍♂️ for some reason I thought there was a difference in granularity between the two, but nobody is tagging their package for a bugfix release. ---
**Author:** ![hauntsaninja](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hauntsaninja/32/12451_2.png) [@hauntsaninja](https://discuss.python.org/u/hauntsaninja)\ **Post date:** [October 3, 2024, 10:27pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/6 "2024-10-03T22:27:31Z")
Thanks for testing against prerelease Pythons! I would add the classifier at the time you get the tests green, but continue to make releases as per your usual schedule. I wouldn’t think reasonable folks would interpret the package as being abandoned. I think it’s kind of silly to think something is abandoned and switch without a) checking the actual project (which in your case would have active commits demonstrating testing on new Python), b) having a direct unmet need (needing something merged/released). And enough people don’t bother doing minor version classifiers or let them get stale that there’s plenty of company. That said, I guess if your last release was years ago and your last classifier was like 3.6, I’d probably assume that your software is either done or abandoned. And it’s fine for software to be done. And it’s also fine to make non-functional releases at a cadence of your choice as a way to communicate liveness and ongoing testing to users. ---
**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\ **Post date:** [October 8, 2024, 1:26pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/7 "2024-10-08T13:26:05Z")
This was brought up this morning in an issue for Hatchling [Please make trove classifier validation optional/non-fatal · Issue #1368 · pypa/hatch · GitHub](https://github.com/pypa/hatch/issues/1368#issuecomment-2399809909) Essentially, there is a check for valid classifiers and older distributions package an old version of `trove-classifiers` so packages that wish to indicate support for new Python versions fail at build time. ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [October 8, 2024, 3:30pm UTC](https://discuss.python.org/t/handling-stale-python-version-classifiers-for-low-churn-projects/66537/8 "2024-10-08T15:30:41Z")
This does sound like Hatchling needs to depend on a recent `trove-classifiers` if it’s going to require a package’s classifiers all exist in `trove-classifiers`. It doesn’t sound like a problem unique to version classifiers – I expect Hatchling could also fail if I’m using a `Framework :: My Cool New Framework` that was added this year but the distro still has a years old `trove-classifiers`.