I finally have a need for being able to use plugins in-place [1], so my
itch is strong enough for me to scratch it. I was about to just go ahead
but David asked a question or two on SVN that made me realise I have not
thought this through properly. So, here is a proposal for a plugin
development/release cycle.
(I'm going to hack a solution locally to scratch my itch, but I want to
create a more robust solution for committing)
The Problem
-----------
There are a number of problems with the current plugin life cycle:
- a network connection is required on the first site build
- if one has the src downloading the plugins is a waste of bandwidth
- plugins need to be locally-deployed for testing if one is developing
plugins it adds an overhead to the development cycle
- the forrestbot is not able to deploy the necessary plugins, so if
using forrestbot-trunk we will not be using the trunk of the plugins
(actually there is a mechanism in the scripts David wrote for the
zone that can be used to deploy plugins, this is a partial solution to
this problem)
- when developing a third party plugin, it may not be deployed to a
server. We can use the file: protocol to retrieve from the local file
system, but that still requires a dev to package the plugin after
*every* change
- with the current deploy mechanism we have no means for testing in
development plugins within our continuous integration testing mechanisms
(forrestbot on the zone) without potentially breaking installations that
are using unversioned plugins. That is, developers are forced to do full
testing before deploying the plugin - we've been stung a couple of times
recently by this.
Proposed Development/Release Cycle for Plugins
==============================================
Development
-----------
Development is carried out using the local source versions of the
plugins (duh!)
No local deploy is necessary, the plugins are used in-place
No restart of Forrest is needed (i.e. it is not sufficient to copy the
src into the plugins during startup)
Unit Testing
------------
The existing local testing mechanisms are sufficient, i.e. "build.sh
test" since plugin src is used in place.
Continuous Integration Testing
------------------------------
forrestbot-trunk uses SVN trunk, as such it checks out the latest
version of the plugin in SVN (i.e. no further changes are needed)
User Testing
------------
Bleeding edge users can use the latest *released* development version by
omitting a version number. Note they do *not* use the trunk version
unless Forrest is able to find the trunk source locally, in which case
it will use that version.
To move a plugin into the user testing phase we will need to deploy the
plugin as a dev version.
Release
-------
After a suitable period of user testing we release the plugin, making it
available as a new version number. The "careful" users can then choose
to upgrade their version numbers or not.
Life Cycle Summary
==================
I propose that each plugin will have up to three versions at any one time:
- dev version (src code local to installation)
- testing version (deployed, but unversioned copy)
- released version(s) (deployed and versioned copy)
How?
====
I *think* all that needs to be done is to enable plugins to be used
in-place [1] and document this.
Any thoughts/comments?
Ross
[1] http://issues.apache.org/jira/browse/FOR-388
