This is not meant to be a session, more a development project.

BlueSpice would also love to take a part in the early adoption. We can test with Extension:Privacy.

@Tam-edwin-microsoft I merged your changes. If you have more stuff that needs to be merged, please feel free to ping me at glaser@hallowelt.com to speed up things ;)

Thanks, Krinkle, and sorry for the extremely late answer :) The https://www.mediawiki.org/wiki/Manual:Cache page is perfect and helps a lot.

This was a task for a hackathon. If someone should restart the work on BlueSpice / Lua, there needs to be a fresh ticket anyway.

I think this is a topic which continually evolves. There is the aforementioned page on MediaWiki, which is designed to keep track of the topic. So I guess this task is done.

This RfC brings a long needed clarification. That's why I strongly support it. There are over 200 extensions out there that can be downloaded using composer, including some heavy-weights such as SMW, BlueSpice, Wikifab and Chameleon skin. Now the RfC basically codifies a best practice and a way forward for a recommended use of composer. Not doing so will not make composer based extensions go away, but leave their developers in a state of insecurity, which is not helpful.

What we are trying to achieve here is to enable a development workflow against the LTS version of MediaWiki. So we use the current MediaWiki LTS version (currently 1.31) as a basis for our extensions. This is mainly because we simply do not have the dev resources to keep updated with the fast moving master branch of MediaWiki. Within the ~2 years of LTS support, we provide bug and security fixes (patch releases) for the current stable extension as well as feature improvements (minor releases). This is why we need to maintain at least two lines of development. I would assume a development workflow against the LTS version is something that is not only specific to BlueSpice, but would strengthen the concept of MediaWiki LTS in general.