forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Plugin development/release cycle
Date Fri, 09 Dec 2005 12:38:24 GMT
David Crossley wrote:
> 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.
>>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.

That's the idea, yes.

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

I would say, yes. People can also subscribe to the changes.rss feed in 
the plugin docs.

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

Yes, I would say that is sensible. We have already seen how releasing a 
plugin causes problems. Requiring vote will ensure a little more 
oversight. However, since many people will not be using the plugin we 
should make it a simple consensus vote.


View raw message