• toastal@lemmy.ml
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    3
    ·
    20 hours ago

    1.0 would be the perfect time to have the code, bug tracker, etc. migrated off of Microsoft GitHub

    • douglasg14b@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      14 hours ago

      Why?

      I know the knee jerk reasons of course.

      However, GitHub is a fantastic ecosystem for an application to thrive. Contributions on other platforms are greatly reduced.

      Then again, the actual Lemmy development is a bit of a mess.

      Once it gains critical mass of engaged developers, that’s a good time to migrate off GitHub. Doing it earlier just slows the project down.

      • toastal@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 hours ago

        It really provides nothing special of note other than network effect (slow UI, nonrobust CI of YAML spaghetti, pull request model is broken, upselling AI shit in the UX, taking users code with that AI & selling it back to users despite it being our code in the commons, taking cuts from sponsors, etc.), but you can’t shift that without setting a good example—& getting folks to cross out of that closed, centralized, data sucking ecosystem.

        One of the primary reasons for Lemmy’s existence is to get out of Reddit’s walled garden & AI nonsense onto a decentralized platform. Git (& other VCSs) does not have a restriction on centralized nonsense unless you buy into a platform that requires give up their data to a US company just to participate. Why would you value one thing for your users then have different values for developers (that are also users)—especially when there are gobs of alternatives? Screw Microsoft on all accounts—historically & presently. There is no reason to treat this like some startup/market thing for engagement when the platform & its core users want a different experience outside of corporate control (but if you must, just make a readonly mirror with issues disabled).

  • db0@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    57
    ·
    2 days ago

    Oof, lots of work to do for everyone.

    If anyone can figure out all the non-mentioned API changes and write them here it would be useful for people like me to avoid having to reverse engineer things

  • davel [he/him]@lemmy.ml
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    2
    ·
    2 days ago

    A lot of these should not be called breaking changes. A new API is not a breaking change if the old API remains.

    • Dessalines@lemmy.mlM
      link
      fedilink
      English
      arrow-up
      58
      ·
      2 days ago

      Lots of things, but mainly that lemmy is pretty stable, and its been a year since the last breaking changes release.

      I was also kind of opposed to a v1.0, and wanted lemmy to be considered alpha/beta level software, because I know when we release a v.1.0, people are going to expect the same enterprise-level and bug-free software from a ~4 person dev team as they do from a multi-million dollar company. Also it gives us less freedom to make breaking changes, which can be restrictive for back-end devs.

      But now we can just adopt proper semver, and the next breaking changes releases can upgrade the MAJOR version.

      • nutomic@lemmy.mlOPM
        link
        fedilink
        English
        arrow-up
        14
        ·
        2 days ago

        On the other hand it gives an indication to client developers that such big breaking changes wont be a regular occurence. So they have a reason to upgrade and then keep using 1.0 long-term. I believe that practically all the needed breaking changes are already implemented, and remaining issues are mostly new feature requests which can be added as new api endpoints or parameters.

          • nutomic@lemmy.mlOPM
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            1 hour ago

            What feature requests will be implemented after 1.0? Everything that’s open on the issue tracker really, as soon as someone works on it.

  • sabreW4K3@lazysoci.al
    link
    fedilink
    English
    arrow-up
    13
    ·
    2 days ago

    This is epic. I really hope Laurence can find some time to make Sync for Lemmy support it.

    • Dessalines@lemmy.mlM
      link
      fedilink
      English
      arrow-up
      21
      ·
      2 days ago

      Can’t give an ETA yet. I’ve got a few more back-end things to finish up, then @sleeplessone1917 and I will work on lemmy-ui.

      Then I also gotta work on getting jerboa updated also. So much work and so few developers.

      • db0@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        5
        ·
        2 days ago

        Ah, good to know before I start developing. Can you let me know when we can start the development as I don’t want to use the API and then discover it’s missing more PRs?

        • Dessalines@lemmy.mlM
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 days ago

          I can’t say yet, as we’re still adding things. If you’re not using lemmy-js-client, then as long as your types are generated from it’s main branch directly, then you should be fine.

          • db0@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            2 days ago

            I’m not using the js-client. I’m updating pythorhead so I need to make sure the API is at the final version before I can match it. And to match it I need the patches to be in so I can read the doc, and/or import the swagger.

            I will do what I can in advance, but to do the pre-development you asked for, we do need the final version up somewhere.

            • nutomic@lemmy.mlOPM
              link
              fedilink
              English
              arrow-up
              3
              ·
              2 days ago

              The final api version would probably be in 1.0-beta.0, which will still take a few months. But at this time you can already start to adapt for the major changes like combined endpoints, and give feedback if anything else in the api needs changing.