podatus

I would rename Check to Must which there is at least some precedent for.

I eat 2 cups of food for lunch on weekdays because if it was good enough for a roman soldier to march on it's good enough for me to go clickity clack on a keyboard.

code review as others mentioned but if everyone is on equal footing in the review then you need some kind of enforceable policy where work isn't merged until a policy team signs off on it. Who is on that team becomes a matter of office politics and navigating such. With support of CTO that can be worked out for designated roles among peers.

If the people on that policy team require too much and slow things down in your fast paced environment then that is another seperate issue to navigate to find the right strategies and methodologies.

no, a summary would be you're asserting whatever lifecycle you're pushing is the only right choice when someone is clearly talking about lts. You said there was no distinction, lts or not, when there is in fact a distinction.

If I start a project in 7, I make plans for the move to 8 in an lts context. When 8 is released and given previous history, I may have as little as three months to move to 8 before support ends. If instead I chose 6, I may have as little as over one year. These are very different things depending on the nature of one's business.

You then also assert one always chooses the 7 patch but completely gloss over or are unaware of the presumptions, e.g. no one planned for the 8 upgrade, no one prepared for the 8 upgrade from prereleases, etc

they will always pick the patch upgrade

this assertion is incorrect. I meant "no shit" choosing the patch upgrade is the easiest choice.

Before any coding has even begun, making the choice of 7 creates in the future the binary choice of either a patch upgrade OR an upgrade to 8. The choice is made based on planning. If you aren't including this binary choice in future plans you need to NOT choose 7.

no kidding, NO ONE is sticking with 7 unless its part of a series of bad choices

being forced to undergo a major version upgrade without being able to do full regression tests is exactly how you get your projects to break, no matter how many LTS dependencies you consume

that's exactly what's already being said. First, there's only one LTS change even being discussed, e.g. no one is talking about moving from 6 to 8 or back porting from an upcoming 8 to 6. Second, if your not going to be bothered with the very preparations your mentioning should be made when choosing 7, then one should choose 6.

The whole point of this thread is that it’s preferable to consume bug fixes in patch releases than being forced to undergo major version upgrades. Do you disagree?

Fundamentally, if I enter into a contract of using 7 then I understand sets of bugfixes won't necessarily be back ported.

do you even .net? "stability trumps the latest and greatest", that's exactly what who you're replying to said. If one is making the choice to use 7 in the context of stability, then one has already planned an upgrade to 8 upon release; otherwise stick to 6.