On 09/06/11 01:22, Mark A. Hershberger wrote: > There has been some talk among developers and others about bundling some > extensions with the tarball. The new installer supports enabling > extensions during installation, so if we're going to do it, I would like > to start bundling them with the 1.18 tarball.
It's a bit sad that we didn't have this ready for 1.17, but there were still a few bugs in the extension installation feature at the branch point. In fact, I see that there was a bugfix merge as late as yesterday. We can probably include a few popular, well-tested extensions in the 1.18 tarball, as a temporary measure while we are waiting for some better form of extension discovery and management. I don't think we want this mechanism to become a substitute for merging extensions into the core. Enabling extensions in the installer is not going to be as user-friendly as just having them merged in and enabled by default. I'm thinking in particular about the older half of ParserFunctions, and the usability initiative extensions such as Vector. So it becomes a question of policy: if an extension is small, popular and uncontroversial, then that's an argument both for merging and for bundling. Bundling is easier for developers, but merging is probably easier for users. You can go either way. Firefox doesn't ship with any extensions. They merge in features from extensions that are particularly useful, and provide a download interface. Wordpress is one that comes to mind that takes the other approach, it ships with Akismet. Remember that most extensions don't have version numbers, there's no way to tell if they're up to date, and there's no way to tell whether they are compatible with the version of the core that is in use. If an extension is bundled and then later merged to the core, there won't be any way to automatically migrate the wikis that used the bundled copy. We can make it easy to install some small set of extensions, but it's not going to be easy to maintain them for a while yet. So there's an argument for keeping the list small and innocuous. -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
