neptronix whose future is uncertain since the API has been in flux for years, and will continue to be
Flarum's UX and UI have been stable for several years now, but we've kept the beta label (which hurts adoption btw) for precisely this reason. After we release stable, we would only include breaking changes (and hopefully somewhat minimal ones at that) quite sparingly. In the backend, the use of extenders as public API means that BC layers should be quite simple to introduce and maintain.
I think the recent beta 14 update actually illustrates this rather well. That update switched from v0.2 to v2.0 of Mithril, effectively breaking every single extension that has a frontend component (most of them). And unlike breaking changes originating from Flarum core code, where we could try and stagger it out, document it well, and provide a lot of examples, this was very "all at once". I doubt we'll have a breaking update as broad and challenging for the forseeable future (Mithril and Laravel are pretty stable). And despite all that, the ecosystem has (almost) completely moved past it!
neptronix 99% of Flarum admins and users will want it. And the only way to get that feature is through an add on
As is the case with tags, mentions, subscriptions, and a good deal of moderation tools. We treat extensions as first class citizens, and a lot of discussion about how extensions would be affected goes on behind the scenes before changes are made. EvilExecutor's idea of maintaining and including bundled extensions is already in play, with 16 bundled extensions (including the aforementioned) that cover a broad overview of the extension API included and enabled by default in Flarum installs. And that actually brings me to:
neptronix This 'small core over all other considerations' mentality is good for your development team, because it minimizes the work you need to do to maintain the platform... but it's a negative for the people who will be running the platforms. Your needs and the needs of people using your platform are of equal importance.
That's actually something I highly disagree with. By keeping core minimal and small:
- There's less public API that could encounter breaking changes
- Community extensions can iterate and develop faster, as they're not bound by the core dev cycle
- There's a LOT less technical debt that would require us to rewrite big parts of core, meaning that breaking changes are much simpler and easier to fix
It's a very unconventional model for the forum world, where monolithic behemoths like phpBB have set the standard for so long. But the more I've worked with it, the better I'm convinced that it's the right way to handle this.