Development goes to fast

Questions
#1

Hey Sam,

at the moment it is really hard to follow the speed of the development of OctoberCMS.

I can understand, that you will go forward with this project but you left all behind you. All known plugins are becomming outdated. All the plugin-repos are becoming patched only by yourself with some fixes but I can see the most well-known plugins are becomming outdated and OctoberCMS is going on a way, which is hard to follow.

Can you please press something like a break on it? It seems like you are running out of all, what October stands over all the years.

Thanks in advance

#2

Hi @neralex

Thanks for raising this.

Can you share a few examples of plugins or recent changes that are causing problems?

We recently upgraded a site that started on October v1 and it came across just fine. We’ve put a lot of effort into keeping the core principles and upgrade path backwards compatible.

We also publish the roadmap so upcoming work isn’t a surprise: https://portal.octobercms.com/

Some plugins will still fall behind when their maintainers stop updating them, but that’s a different problem from October itself moving too fast.

If there are recent changes making plugin maintenance harder than it needs to be, I’d like to understand where.

#3

This is the only CMS where I have to built plugins, which supports other plugins, which are not more supported by the plugin-authors and after each system upgrade I have to go through all of it. I would really like to get an overview but the row is becoming more and more heavy. It feels like the eco-system is collapsing around the cms itself because many plugin-authors are moving away.

#4

That makes more sense, thanks for clarifying.

It sounds like the main burden is maintaining compatibility for plugins that are no longer supported by their original authors, rather than the October upgrade path itself.

If you have a few examples of the plugins causing the most trouble, that would be useful.

#5

My honest point of view:

  • Third-party plugins that are no longer maintained are unfortunately not really an OctoberCMS problem. This is something every ecosystem has to deal with, especially when a plugin depends on internal APIs or on other abandoned plugins.
  • With the arrival of AI, I actually expect the way we use third-party plugins to change quite a bit. Personally, I’m increasingly inclined to build a small, purpose-specific plugin myself rather than introduce another dependency just to solve a relatively simple problem. AI makes this much more practical than it used to be.
  • The first-party plugins, such as RainLab.*, are still being maintained, so I don’t see the same issue there.
  • I also think some of the recent core improvements actually reduce our dependency on plugins. For example, in 4.4, URL routing/multisite functionality was brought into the core. This means you can now run a multilingual/multisite website without necessarily needing RainLab.Translate for that particular functionality.