• rmam@programming.devOP
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 year ago

    do you even .net?

    Yes, I do. Do you?

    that’s exactly what who you’re replying to said.

    Not really. Stability does not mean consuming a package that’s supported for a long time. Stability is a function of the work you put into your project. You can consume all the LTS stuff you can think of, and still release an unstable mess.

    In this case, 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.

    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?

    • podatus@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      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.

      • rmam@programming.devOP
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 year ago

        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.

        It sounds you lost track of the discussion. OP clearly pointed out the scenario of being forced to upgrade to 8 instead of sticking with 7.

        I don’t think it’s worth to continue discussing this. Apparently you’re arguing without context and in the process talking besides the point.

        • LeFantome@programming.dev
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          You may actually get the other guys point but it does not sound like it.

          Based on Microsoft’s support cycle for .NET releases, if you start a project in .NET 7, you already knew on that first day that you were going to have to upgrade to .NET 8 by May 2024 at the latest as .NET 7 becomes unsupported then. Not just to upgrade, to upgrade to .NET 8 specifically.

          I guess you could roll back to .NET 6 until November 2024 but that seems pretty insane. When you choose .NET 7, the choice to upgrade to .NET 8 is baked in before you write a single line of code.

          That is why complaining about “being forced to upgrade to 8 instead of sticking with 7” sounds like a weak argument.

          If you choose .NET 6, you can stick with it all the way to .NET 9 if you really, really want.

          In .NET, even numbered releases are for people that do not want to be “forced to upgrade” and odd numbered releases are for people that want to stay up-to-date with the platform (which means adopting new releases as they come ).

          I guess another choice is to use unsupported releases. However, if that is your choice, complaining about a lack of bug fixes in the release you are using is obviously bonkers.

          While it is a bit aggressive, the question “do you even .net” is, I think, questioning if you understand the .NET release cycle and the implications of choosing one release over another when you start a project.

          Taking a step back, it makes a whole lot of sense that Microsoft would be putting their bug-fixing energy into .NET 8. After all, as an LTS release, some people may choose to stick with it until .NET 11 is out in November 2026. If you are going to invest in fixing bugs, would you choose the release that almost everybody is going to stop using in November 2023 or the one that many projects will use for 2 - 3 years longer than that?