forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Plugin development/release cycle
Date Fri, 09 Dec 2005 11:01:11 GMT
Thanks for thinking out aloud. That certainly helps.

> 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.

So when we release a plugin then we increment its
version number in the of the
template "seed" sites. At release time, they will
be declaring specific release numbers, and users
take it from there. Is that the idea? Sounds good.

How do people know when new versions of the plugins
are available? At least we would add to top-level status.xml
so that it gets listed on the changes.html page.

Do we make an actual announcement too?
The project is supposed to vote on a "Product release".
That action was written with the traditional "Release"
in mind (i.e. 0.7 then 0.8). I wonder if it should
apply to our plugins too.


> 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]

View raw message