EnablingIncrementalCoreUpdates

Using the Extension mechanism for small incremental Core updates

We need a easier way to bring out small core updates and fixes without going through the whole release process. This could be done without any core changes and using the extensions mechanism we have today.

General Extension names

The extensions would be named for the Release and Rev number they apply. For example, Foswiki 1.0.9 was released at r6076. If some significant updates were desired at r6200, the following update "extension" would be generated: FoswikiPatch109r6200. The "Extension" would contain the incremental updates between two svn build numbers.

Generating the incremental package

Find all the changes between the previous update package or release

 /var/www/SVN/foswiki/branches/Release01x00 $ svn diff --summarize -r6076:r6200
M       BuildContrib/lib/Foswiki/Contrib/Build.pm
M       core/AUTHORS
M       core/pub-htaccess.txt
M       core/tools/pkg/build_deb.sh
M       core/tools/pkg/debian/changelog
M       core/tools/pkg/debian/apache.conf
M       core/lib/Foswiki.spec
M       core/data/System/WikiSyntax.txt
M       core/data/System/WikiWord.txt
M       core/data/System/EditingShorthand.txt
A       core/data/System/ACRONYM.txt
M       core/data/System/TextFormattingRules.txt
M       WysiwygPlugin/test/unit/WysiwygPlugin/ExtendedTranslatorTests.pm
M       WysiwygPlugin/lib/Foswiki/Plugins/WysiwygPlugin/HTML2TML/Node.pm
M       TablePlugin/lib/Foswiki/Plugins/TablePlugin.pm
M       TablePlugin/lib/Foswiki/Plugins/TablePlugin/Core.pm
M       TablePlugin/data/System/TablePlugin.txt

These files would be copied (or symlinked or hardlinked) into the upgrade package, discarding the top level of the directory. Files not distributed would be ignored. This would result in an "extension"with the following structure:

• FoswikiPatch109r6200
  • AUTHORS
  • pub-htaccess.txt
  • lib/Foswiki.spec
  • data/System/WikiSyntax.txt
  • data/System/WikiWord.txt
  • data/System/EditingShorthand.txt
  • data/System/ACRONYM.txt
  • data/System/TextFormattingRules.txt
  • lib/Foswiki/Plugins/WysiwygPlugin/HTML2TML/Node.pm
  • lib/Foswiki/Plugins/TablePlugin.pm
  • lib/Foswiki/Plugins/TablePlugin/Core.pm
  • data/System/TablePlugin.txt

In addition, the standard package files would be needed.

lib/Foswiki/Contrib/FoswikiPatch109r6200/MANIFEST

Contains the above file list

lib/Foswiki/Contrib/FoswikiPatch109r6200/DEPENDENCIES

Requires the prior Foswiki release, or the prior patch release.

lib/Foswiki/Contrib/FoswikiPatch109r6200.pm

Stub file to establish the VERSION for dependency check.

data/System/FoswikiPatch109r6200.txt

Changelog - extracted from svn log -r6076:r6200

Installation

Installation would work like any other extension, however we might want to store these in an alternate repository to avoid cluttering the Extensions web.

By isolating the update packages to an alternate repository, one possible core change would be to have the intro page of bin/configure search for new updates, so that they become more visible.

Issues

Installation of a new Foswiki release would need to remove the record of the Patch extensions - since they would no longer be applicable to a new release.

We would either have to disable un-install for these patch packages, or use a different mechanism, possibly restoring the backup created when the package was installed. Uninstalling (and removing the critcal system files) would be fatal.

If we don't distribute a new Foswiki.pm, the updated rev won't be reflected in the Foswiki version.