• trolololol@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    2 months ago

    Assuming that they will do EEE here once more, can the community fork the latest version of. Net and do with it whatever they want, including maintaining cross platform support if MS decides to abandon that part?

    • DacoTaco@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      2 months ago

      The mit license allows forking, merging, modifying and releases of modified code. Yes id assume so yes :)
      I have a lot of bad things to say about some microsoft teams and some microsoft managers (cough fluentui webcomponents team cough ), but in general the .net team is a nice one and ive had several nice encounters with few of its devs.
      Just dont know what the actual bloody fuck the manager/team was thinking dropping linux when they made maui…

      • taladar@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 months ago

        What I would really like to know is the thought process behind using the oldest dependency version in a version range in .NET instead of the newest like literally every other package or dependency manager ever made. That design couldn’t be worse if it was designed to maximize security holes.

          • taladar@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            1
            ·
            2 months ago

            If you specify that e.g. a dependency should be between version >= 4.0 and < 4.1 in dotnet and there are versions 4.0.0 and 4.0.1 available pretty much all other systems choose 4.0.1 based on the idea that that will include a fix while dotnet chooses 4.0.0 based on the idea that that is “more stable”.

            • DacoTaco@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              2 months ago

              Ah, thats fair. I think thats fixable using wildcards in the packagereference in the csproj, but id need to check. I too would expect it to choose 4.0.1 unless a patch release needs a big update or something