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.

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.