https://plone.org/security/update-policy states that hotfixes are
.. available for the current and the previous major release
Currently, that means the 5.x series and the 4.3.x series.
however i could not find any information when 5.x will be superseeded by 6.x (or whatever the version is called) and 4.3.x will no longer receive security updates.
i know it is hard to tell a definite date, just want to get an idea. 1 month, 6 months, 1 year, 2years?
I think, not confirm, that as long as there is no Plone 6.0 final release there will be hotfixes for 4.3.x.
This means that first we need a 6.0 branch, then alphas, betas and release candidates...
So at least years, in plural I would say.
At least I would not start worrying until I see the 6.0 branch created on buildout.coredev.
Last I heard this discussed in real life was at the Plone Boston Conference in 2016. By the letter the update policy is as @gforcada explains, but there was an argument made by community members that this does imply that the CI infrastructure then has to support 4 releases or even more at the same time. 4.3.x, 5.0.X 5.1.X and 6.X when its development starts. Is this doable?
Also there's a difference between update policy and 'security' update policy, but both need CI to be workable I guess.
What's not in an official update policy that I can find is how long the previous minor version will be supported. Plone 5.0 hasn't seen an update since June 2017 (there's a pending 5.0.9 from august). Are 5.0.X users expected to upgrade to 5.1 now that it has been released, or will we keep at least to minor versions supported in the current main release version? (5)
Apart from any official policy: the Plone Security team has usually done a great job providing security related hotfixes even for very old Plone versions. Given the large amount of Plone installations that are unlikely to be moved to Plone 5 or 6, there is need for longterm support of Plone 4.3.X.
-aj
I would expect that bug fix releases in the 5.0 line will continue.
That may be so, but since (as always) there are limited resources, individuals and organizations who require longterm support of no longer officially supported versions can contract with Plone service providers.
The ongoing release of new Plone versions is a good reason for staying on an upgrade path.
Call BS as long as you want but we have enough customers that will either migrate away from Plone or stay on the current version for the time being for a variety of reasons.
A question of resources, money, and risk that customers want to accept.
Fortunately there is some new Plone business this year but I don't see any customer in our longtime customer base that will move to Plone 5 over the next two or three years.
-aj
Plone 4.3.x will continue to receive hotfixes and bugfix releases until Plone 6.0 is released.
We and other Plone solution providers have been doing this for multiple years, patching and keeping installed Plone 4.x running more or less smoothly with the changing requirements, external environment (browsers), and fixing long tail bugs that only occur very seldom or in uncommon combinations/setups.
Bugs are patched, core packages are updated and registered in buildout.coredev, but these fixes don't end up or end up very slowly (10 months?) in minor Plone releases. So while providers and developers are patching their customer installations (of the customers still left) with in between patch-lists of updated packages in their installs and contributing these upstream, the sink seems to be clogged at the end of the pipe.
The effort to "support of no longer officially supported versions " is at the moment de facto equal to support the official versions when there are no minor releases: you need some decent Plone experience and information of package dependencies and individual components to pull this off.
I was talking of longterm support regarding security related fixes. I was not talking about LTS support in general. I am fully aware that this is not possible due to the resource problem.
-aj
We have tried to test security fixes on very old (so old they are well out of official support) versions. It has gotten harder and harder to build old versions because so many of the requirements are themselves no longer supported on current OSs.
For the record: Plone 3 is really not supported anymore, not even by hotfixes.
The security team added some warnings in the hotfix from November 2017 to make that clear.
Plone 4 versions in combination with Python 2.6 are on a dangerous point. Python 2.6 has reached end-of-life in 2013 (five years ago) and has no Python security support since then. Usually a Plone security hotfix will work fine on 2.6, but it is getting harder and harder to test. This may force us to give up. I think most Plone add-ons are only being tested on Travis CI with Python 2.7.
Is anyone using Plone 4.3 with Python 2.6? Or maybe Plone 4.2 with Python 2.6?
At least Jenkins and I'm so willing to drop that as soon as possible 
Absolutely! Perhaps the upcoming Plone 4.3.17 release would be a good moment to drop Python 2.6 support. We should make it clear in the announcement that 4.3.17 is the last to officially support 2.6.
as plone4.2 is not officially supported and upgrading to 4.3 is not a big deal i'd say here is no single reason to still maintain tests for python2.6
Currently, Plone 4.3 is still officially supported on Python 2.6, and we run tests for it on Jenkins.
thanks for your clarification maurits. i just wanted to state that we need not care if anybody uses 4.2 with python 2.6.
when it comes to 4.3: dropping official support for an unsupported python version won't really do additional harm.
downside: this needs to be stated in the changelog and probably documentation/release pages will need to be updated too.
btw: do we intentionally omit python versions in the setup.py classiefiers (https://github.com/plone/Products.CMFPlone/blob/4.3.17/setup.py)?
Sorry, I already forgot that I also asked about Plone 4.2.
No, not intentionally. I am usually adding and editing them before I make a release.