On updating

010101

I think that requiring certain versions of things is necessary for many things, but not extensions. I'm on my third Flarum site's upgrade and it's fairly cumbersome because I have to remove incompatible extensions and then probably due to my version of composer and hosting environment I have to do other workarounds. If things don't update in exactly the right order you're stuck until you remove certain extensions. Even if some of the extensions are in fact compatible, if the update fails in the middle you might be left removing extensions which have compatible versions out there because for whatever reason they won't update.

So, my proposal is that Flarum shouldn't be as strict when it comes to extension versions. Let the core update no matter what. If there are errors, then the webmaster can troubleshoot which extension is causing it by deactivating and reactivating one at a time, like you have to do anyway.

Isn't a lot of popular software like this? You can update the core, and then if an extension you have stops working you remove it. But, you don't have to do all kinds of extra composer commands. And, since the new admin dashboard has those dots next to extensions, a certain color could mean, warning, do not activate this extension, it isn't compatible.

clarkwinkelmann

This can in part be achieved by setting * in composer.json. This makes Flarum install any compatible version of an extension, but is still constrained by which versions of Flarum an extension supports.

You could go further by setting Composer version aliases to bypass checks and assume a version is compatible with another.

Using ^ constraint with Flarum beta used to be very permissive. But we then changed the recommendation to use upper limits because of the huge support pain caused by people installing very old extensions that completely destroyed the forum, as well as the foreseen breaking changes ahead.

Because of the important breaking changes we introduce, we can't have error handling for all previous features and incompatible extensions often cause the whole forum to break down and requires manual intervention to restore it.

I personally think it's preferable having a Composer requirement issue well in advance, instead of a broken forum that the user may or may not know how to fix.

010101

clarkwinkelmann I did the "*" trick but due to an incompatible extension the update still stopped. At that point I had to remove 8 extensions one by one even though 6 of them, once updated, would have been compatible. The two incompatible ones stopped the rest from updating and thus stopped core too. Since I couldn’t update core, I couldn’t update the constrained extensions either.

There's got to be a better way for shared hosting folks who may have older composer versions and maybe other things going on.

Once I got to my third forum that I was updating I knew exactly which two extensions caused the problem so as step one I removed them, then the update went great.

Well, that’s my opinion. One old extension shouldn’t stop a core update. You instead warn that extension XYZ may not be compatible based on its version constraints. Let the forum owner decide whether or not to take the risk. It’s their forum. Maybe they want to be crazy and take a risk. 😁

luceos

010101 have you tried the extiverse helper, if so did you run into issues with that as well?

clarkwinkelmann

Once Flarum reaches stable, proper semver will be usable. Extensions will be able to mark compatibility with Flarum ^1.0.0 and will be installable on all future Flarum versions below 2.0.0.

010101

clarkwinkelmann Oh, ok. That solves it then. 👍

010101

luceos No... In the past, for the most part, I didn’t have the issue I had this time. So, I didn’t think I would need the helper. I thought that as long as I had extensions which have all been updated for beta 15, I'd be OK. And I thought I had all beta 15 compatible extensions but I overlooked a couple. Maybe I would have had this same issue with past betas... it seems like something is more strict this time.