I was hoping to be able to push this off a bit further, to give more of you time to migrate, however lately the amount of work needed to keep OctoPrint running under Python 2 – which now has been declared end-of-life for two full years – has increased to ridiculous amounts.
Do it. (Frankly I was expecting this step a lot sooner …)
Wow, you still supported python2? impressiv! everybody who depended on this, was very lucky to have such a caring project owner to give her/him/them 2 years(!) of time for a transition. This was enough time.
for my projects I dropped python2 support the day it was declared unsupported 
Sounds like a sensible decision to keep OctoPrint development from being dragged down by EOL dependencies.
Much better to have development going faster so we get new shiny features sooner.
Ha! You're much kinder that I would have been. If THEY'RE not even supporting it anymore, I would have long since pulled support!
This does make sense. No need to waste resources on something obsolete.
I am probably going to get blown up for this:
How do I go about this OctoPrint needing Python conversion?
Main post with all the explanation is here:
Edit: has now been added to the original post
Thank you. I poked around before asking, but wasn't sure what I was looking for.
I am not a python developer, so I don't know how things like this are typically done in Python, but you should consider using SemVer. Basically, dropping support for Python 2 would be considered a breaking change, and thus you should increase the "major" version number (2.x.x). That you had other plans for what would be included in 2.x.x is immaterial. You version based on the changes you've made, not based on what gives you the warm-fuzzies.
It's not breaking if python2 users are not provided the opportunity to upgrade. Python2 users will simply sit in limbo on 1.7.3 forever until they decide to upgrade their python environment or reflash OctoPi with a newer version.
Since it's not guaranteed to know by version (ex. 0.18 dev version), is there a way to check to see which version of Python is running? I see these mentioned in my System Info...
env.python.pip : 20.3.3
env.python.version : 3.7.3
env.python.virtualenv : true
That`s one way to check it, the versions are also displayed in the lower left corner.
You will also see a notification if you're still running Python 2.
We really don't need anyone lecturing @foosel on how to versioning her software.
Why do you think this is the right way to approach someone with your views on this topic?
I've stuck to semver for all of OctoPrint's development so far, which was often very very painful. Given how often I've had to do hotfix releases or new RC rounds because the one or other dependency broke even on patch version increases, I'm at a point where I won't make my life even more difficult for pure semantics that frankly nobody besides a small handful of people even seem to remotely care about in this particular case which strictly speaking also doesn't even classify as the "breaking API change" that would mandate a major version increases following semver - the API stays as is, it's the required runtime environment that changes.
1.8.0 will have all the necessary flags set to not install under python 3 (instead of installing but then breaking, and I spent several hours just yesterday to ensure exactly this), people on python 2 will be redirected to a working and heavily pinned legacy version that should hopefully just continue to work for them for a while to come. I'll continue to stick to semver for development related changes (think internal footprints and other changes in the documented API that plugin and third party client developers work against), but I'm drawing the line here for once given that I've taken all kinds of precautions to prevent breaking changes from actually taking place for people (something that cannot be said to most projects out there) and given that I will have to introduce actual breaking changes in 2.0 it would otherwise just cause a total disruption that would cause me a TON of communication overhead.
Development philosophy is nice and well, but in reality you sometimes you just have to be pragmatic instead of sticking to lofty principles and confusing people in the process more than helping them.
Glad to know you're aware of SemVer and considered it. That's all I wanted to accomplish. 
I disagree with your conclusion, but that's ok. I still love OctoPrint (It's amazing!) and will continue to use it, and I'm not at all upset with you or anyone here. I don't know why a few people seem to have been upset my my comment. 
To give but one example, when projects in the Node.js ecosystem drop support for an old version of Node, most consider that a breaking change, because it is not safe to blindly upgrade. Of course no software is perfect, but my interpretation of the SemVer rules is that as long as the major version hasn't changed, I should be able to accept any minor/patch upgrades without any danger to my project breaking, because the version number indicates that only feature-additions and/or bug fixes were made. If I happen to be running on an old version of Node (or Python) and upgrading to a new minor version of the library/app broke things, that would be a violation of (my interpretation of) SemVer.
Anyway, thanks again for a great project, and keep up the great work. 