Here we go again 😉

v1.2.0 was just released, let's continue keeping you all in the loop about our progress as much as we can.

luceos stickied the discussion .
2 months later

Hi everyone! It's been a while since we've had an update here. The past few months have been pretty quiet from a core perspective: we've published a few small bug fixes and tweaks, but overall we decided to take some time off as a break following several back-to-back very large releases.

Behind the scenes, a lot of work has been going into researching, planning, and preparing for a switch to using a single monorepo for development of core and bundled extensions. We'll post more about this soon, but the general gist is that it will let us keep all PRs in one place while also making it easier to ensure that changes in core don't break extensions. I'll be working on this over the next few days, and will post an announcement with more information soon.

    Quick update before I wrap things up for tonight. The monorepo has been created over at https://github.com/flarum/framework, and all open issues have been moved to https://github.com/flarum/issue-archive/issues. I've also created a draft version of a script to split the monorepo into subrepos so it can be released.

    Tomorrow I'm hoping to finish up that script, use local dev versions of npm libraries in the monorepo, post some guidelines on creating issues/PRs, and continue working on fixing some TypeScript issues that should allow extensions to type-check their frontend code.

    TODO

    In order of priority:

    • Fix typing issues in core's generated dist types
    • Document issue/PR protocol
    • Start on a primitive "release" script
    • Update links to code in the docs
    • Update links to code in the code
    • Move reusable scripts to flarum/framework from flarum/.github
    • Move webpack and prettier config under @flarum namespace
    • Auto-generate changelogs
    • Add prettier to monorepo
    • Write a formal announcement explaining all of these changes
    • Modify Flarum CLI to support requiring yarn 3 (files only created if template params have a certain value) (actually rewrite this into generalizable "create if X" function for files
    • Set up GH actions scripts to close new PRs in read only subtree splits
    • Add monorepo infra modules with their own scaffolding

    2022-03-11 Update

    Accomplished today:

    • The split script has been tested and confirmed to work. The main branches of all Flarum repos used in the monorepo are now split from the flarum/framework monorepo. It is available as flarum-cli monorepo split.
    • All package repos now use code split from the monorepo as their default branch. The repo descriptions now also indicate that they are read-only.
    • The monorepo now uses yarn workspaces, allowing us to make changes to our webpack, pretttier, and typescript configs much, much, much, (did I say much) more easily
    • Fixed an issue with the reusable workflows so that GitHub actions in pull requests in the monorepo run properly.
    20 days later

    GitHub Action Consolidation

    The initial version of the monorepo had separate GH actions scripts for the frontend/backend of every extension / package. This results in a lot of unnecessary jobs running, which leads to rate limiting. Additionally, we can't have separate "build dist js" jobs for each package. A few thoughts on needed changes:

    • Frontend jobs should only run on changes to some //js/**/* paths
    • Backend jobs should ignore changes to the aforementioned //js/**/* paths
    • All frontend jobs need to be consolidated into one GH workflow, so that we can have one step for building all JS. There's several options for doing this, but my thinking is as follows:
      • For each type of check (test build, build, typescript, prettier, type coverage), we'll have Flarum CLI generate a comma-separated list of paths to packages where the checks apply.
      • Adjust action-build to support js-path as a comma-separated list. It should then perform the build step for every subdirectory instead of for just one.
      • Wrap the typescript, type coverage, and prettier checks into bash for loops.
      • Consider combining prettier, typescript, and type coverage under one "static analysis"/"linting" step to avoid duplicating some actions.
      • Run no-commit "build" steps before the typescript check, so that changes to dist-typings are taken into account properly.
    • Reusable workflows need to incorporate fail-fast into their matrix strategy.
    • We'll keep backend PHP jobs separate for now, as the test suite for every package is different, and has different dependencies. However, this might be worth combining too, eventually.
      15 days later

      Apologies for the lack of updates since this amazing update by askvortsov. Most of our team are caught up with other things momentarily, the release of v1.3 is delayed due to that.

      We have a meeting planned to schedule the release of v1.3 and to talk about the next steps.

      If you are interested in Flarum and would love to contribute to it, we could seriously need you. There's plenty of stuff to do, even testing the new releases as QA for instance. If you're interested, ping me on Discord (https://flarum.org/discord/).

        If someone want to teach me about qa tests, I can defini

        TB54 extension manager is near….developers are working hard 💪🏻

          a month later

          We have completed QA for the upcoming release of v1.3. The three issues that surfaced from it have been dealt with already. Yesterday the newest changes have been published on this community for better stress testing (yes you are our guinea pigs 🙈 ).

          The changelogs have also been completed and mostly consist of fixes. Two of these include improvements to Flarum in handling the full spectrum of Unicode characters in search and slug generation 👏.

          We're hoping to be able to release v1.3 soon. Stay tuned!

            Hari on top of things I see 😉

            We still have a few things to finish before being able to publish v1.3 like the announcement and perhaps an upgrade guide for developers. But I have good faith we can release v1.3 before the end of next week.

              The announcement has been drafted and developer upgrade guide published, but due to some last minute bugs which we already resolved we won't be able to release this week as was originally planned. Yeah I said something else yesterday, but our motto remains "Underpromise, Overdeliver".

              Please help us test this release by posting under the Test Posting tag. If you encounter any issues please report them under Support with a subject prefix with v1.3 so that we can hop onto them before next week and ship v1.3 to you without further delays.

              Enjoy your weekend everyone!

                With 1.2 I reported a few bugs (with extensions mostly and one with Flarum core) due to installation in sub-folders. I hope you can also test with such a forum somewhere too before releasing it.

                We are aware of the notification dropdown being broken.

                edit; fixed 😉

                New package manager 🔥😍🔥😍🔥😍😍🔥
                we don't need access to ssh anymore 😍

                run global update feature 🔥

                  Will this release be fully compatible with PHP 8.1? Without generating some warning messages that fill-up the log (what I had experienced with 1.2 and had to downgrade to PHP 8.0)

                    luceos unstickied the discussion .