Feature Proposal: Formally support multiple extension versions

This proposal is being split into 3 separate proposals:

• This proposal - Support versions of plugins including dependencies and extension categories
• EasierMirroringOfExtensionRepositories - to cover enhancements to BuildContrib and the new Local repository contrib.
• AddExtensionRepositoriesToFoswikiOrg - covering adding Testing and Archive locations to foswiki.org

Motivation

Extensions are critical to the operation of many Foswiki installations. While Core goes through a release process, with release candidates, and thorough testing, Extensions is a single stream of latest versions. In addition, Core extensions get released into Extensions web without necessarily going through the same process.

• Clicking "Install" from bin/configure always gets the latest version
• We have no simple way to get the same version as tested on a different server.
• There is no fallback by using bin/configure to select a previous version
• Limited version dependency support.
• No way to tie plugin versions to core versions.

Description and Documentation

Requirements

1. Allow new plugin versions to be released without overlaying the current stable version
2. bin/configure needs to find stable version and/or unstable versions.
3. Continue to use Foswiki for extension distribution.
4. Backwards compatible to previous Foswiki installs. We can't break bin/configure in the field.
5. Plugin topic should list versions of plugin including beta, stable and previous versions.
6. Plugin documentation topic of Beta, Stable and previous versions should also be available.
7. Users should be able to implement their own Extensions repositories

Potential Solutions

• Create a new subweb named Extensions/Beta This web will be used for developers to release extensions without overlaying "stable" version.
  • Separately addressed in Add Extension Repositories To Foswiki Org
  • Only fully addresses 1-4
  • Only supports a single beta version, and no back versions.
  • Could be extended to include an Archive/Obsolete category
  • Cleanup issues

• Implement versioning through Extension names: MyPlugin, MyPlugin-<version> or similar
  • Potential to address all requirements
  • Need to be creative with backwards compatibility
    • Versioning should not extend to the actual installed plugin
  • We don't have consistent versioning in plugins, as was hashed out in $REVISION$ / $VERSION$ discussions

• Implement versioning through the RCS system.
  • potential challenge - attachment versions are independent & disconnected from topic revisions.
  • Pointed out on IRC - need a better RCS system than currently in use

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 11 Feb 2010

Discussion

Webs are best used as a sort of sub-wikis like a sub-domain in hosting language. I'd better not over-use webs for structuring content that belongs together as natural as stable and beta releases of the same extension. Instead, we should enhance the BuildContrib to allow to upload to the same extensions topic but attach the beta version with a different naming scheme.

Have a look at Drupal

-- MichaelDaum - 12 Feb 2010

I would strongly prefer to have access to a continuous stream of released versions. So strongly that I don't consider the Beta web approach a viable solution.

The Extensions repository was developed from a flat web of topics that had manually created zips attached. It has evolved into a semi-automated repository, but still has strings back to that old manual system. If we are going to re-engineer it, we should be prepared to cut those strings.