forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Plugin development/release cycle
Date Fri, 09 Dec 2005 09:59:15 GMT
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

Mime
View raw message