• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: June 16th, 2023

help-circle


  • 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


  • podatus@programming.devto.NET@programming.dev*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    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.




  • 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.