Talk:Request for Comment/Hybrid extension management: Difference between revisions

From MWStake
Jump to navigation Jump to search
(Created page with "==Improvements of ExtensionRegistry== Let's assume "ExtendedVisualEditor" extension has a dependency to "VisualEditor" in version "1.31", but "VisualEditor" is not enabled or...")
 
mNo edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 14: Line 14:
==Further notes==
==Further notes==
* To discuss: Drupal as an example of how Composer was adopted by a project as "module (=extension) management tool" (later!)
* To discuss: Drupal as an example of how Composer was adopted by a project as "module (=extension) management tool" (later!)
== Looks good to me ==
As someone that has been using Composer in several extensions for many years, this proposal looks good to me. --[[User:Jeroendedauw|Jeroendedauw]] ([[User talk:Jeroendedauw|talk]]) 12:48, 3 April 2020 (EDT)
== Moved to RFC on Phabricator ==
Recently there has been movement in MediaWiki to [https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/551346/ remove composer completely] ([https://phabricator.wikimedia.org/T249573 RFC]).
As a result, we are not able to iterate over this RFC here and I have moved it to an [https://phabricator.wikimedia.org/T250406 RFC for MW on phabricator].
Please comment and add any improvements there.

Latest revision as of 19:49, 16 April 2020

Improvements of ExtensionRegistry

Let's assume "ExtendedVisualEditor" extension has a dependency to "VisualEditor" in version "1.31", but "VisualEditor" is not enabled or enabled but in version "1.35". Current situation is that putting

wfLoadExtension( 'ExtendedVisualEditor' );

to LocalSettings.php will result in an uncatchable Exception, which will bring the wiki down.

Rather than this, MediaWiki ExtensionRegistry should just "load" but not "enable" it. It could then be listed e.g. on "Special:Version" as "disabled". The actual way of how to implement this still has to be discussed.

Notes about Composer as a build tool

  • BlueSpice wants real version constraints instead of dev-REL* (later!)
  • Versioning of MW Extensions instead of relying on release branch (later!)

Further notes

  • To discuss: Drupal as an example of how Composer was adopted by a project as "module (=extension) management tool" (later!)

Looks good to me

As someone that has been using Composer in several extensions for many years, this proposal looks good to me. --Jeroendedauw (talk) 12:48, 3 April 2020 (EDT)

Moved to RFC on Phabricator

Recently there has been movement in MediaWiki to remove composer completely (RFC).

As a result, we are not able to iterate over this RFC here and I have moved it to an RFC for MW on phabricator.

Please comment and add any improvements there.