At the pace of our (currently 'minor', contrast to 'patch') releases there are about 2-4 / year. I agree with the idea of monthly bug fix patch releases.
Declaring the first minor of each year as LTS for 2 years, we could get security fixes into legacy users hands. It would be a good starting point for anyone trying to patch some version between LTS and LTS-1.
Those that don't update for years seem to rarely pay much attention to vulnerabilities anyways, and distributors choose their own path, so this seems like a good compromise.
Security fixes -> trunk (next minor) > current minor > last LTS major.minor > previous LTS major.minor.
I agree with Eric that optionally enabling a fix during the current minor might be useful (think HTTP_PROXY protection), but these would rarely map to the behavior of the next version minor (optional for patch, but default to new recommended behavior in next version minor.)
> Should we also need some kind of LTS version? If yes, how to choose them?
I think it would be required with frequent minor releases.