forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Managing plugin releases
Date Wed, 26 Jul 2006 14:32:53 GMT
Tim Williams wrote:
> On 7/26/06, Ross Gardler <> wrote:
>> Tim Williams wrote:
>> > On 7/26/06, Ross Gardler <> wrote:
>> >
>> >> Tim Williams (JIRA) wrote:
>> >> > Discussed here to:
>> >> >
>> >> >
>> >> > I still agree with what I proposed in that mail.  I actually like
>> >> Ross' suggestion too but only if we move towards better
>> >> packaging/managing/releasing of plugins.
>> >>
>> >> What do you think is needed?


>> > o) Improved versioning - externally identifiable.
>> What do you mean "externally identifiable", is it not sufficient i the
>> current form i.e. "pluginName-0.1", "pluginName-0.2"
> Shucks, I could be showing my ignorance on this plugin versioning
> stuff, but when I go to:
> I see only plugin names, not versions.  I would expect to see
> or some such.

Take a look at

see the version numbers?

It works like this:

no version number means the version is not an official release it is an 
"in development" release. This is what is used if no version number is 
placed in the file.

with a version number it means it is an official release (not that we 
have a process for official releases yet). Such releases are stable and 
will never change. This is what is used if a version number is expressed 

This is "documented" at [1] (docs certainly need improvement)

Doing "ant deploy" on a plugin will deploy the *in development* version 
this can be done much more frequently than a release as it does not 
require the same attention to detail as a full release.

Doing "ant release" on a plugin will deploy a *release* version, 
complete with version number.

David and I discussed this a great deal in an early Forrest Friday. We 
started some documentation for the release process [2]

Does this satisfy your needs?

>> > I'm talking about manually not automagically.
>> Why manually?
>> Even if there is a good use case it can already be done manually using
>> the existing ant targets. It's not documented that way as I've never
>> considered a user needing to do this.
> There are very large intranets in the world today that are not
> connected to the internet.  I don't think we can assume an internet
> connection.  What's needed is the ability to burn plugins to CD and
> use the "sneaker-net" to move it to the running forrest application.

That has always been supported. Just create a plugin repository on the 
Intranet and point Forrest at it.

>> > o) Combined with the above, improved manually downloading of plugins.
>> OK the plugins index page needs download links to the actual files
>> rather than the download directory and it should have instructions on
>> where to save the files.
> Right and, I think, a list of links of the different versions
> including "Latest" an "Previous".


>> What else needs to be improved?
> Probably a better plugin page in general.  It's currently an
> overwhelming laundry list of plugins.  Maybe we should consider only
> listing the plugin names with one-line descriptions then deferring the
> rest of the content to the plugin docs?

The page is currently generated by the sitemap.xmap:

<map:match pattern="pluginDocs/plugins_(.*)/index(|\.source).xml" 
           <map:aggregate element="pluginList">
             <map:part src="{lm:plugin.descriptor.forrest}"/>
             <map:part src="{lm:plugin.descriptor.whiteboard}"/>
           <map:transform src="{lm:transform.plugins.xdoc}"/>
           <map:serialize type="xml"/>

(not saying you should do it, I'm putting a useful reference here for 
anyone who has the urge - I'll link this thread to the issue in a few 

>> However, why would anyone need to download them manually? Cyriaque has
>> solved the proxy problems as far as I can tell, what else would force
>> manual download?
> As I say above, there are some folks that are physically disconnected
> from the internet and the "automagic" stuff doesn't work.

I beg to differ. See my comment above.

If there is one central Forrest installation for the whole Intranet then 
just drop the required plugin zips into the install directory.

If there are multiple installations of Forrest on the Intranet then 
create a local repository and use that. Synchronise it occasionally with 
the live one and bingo all your installations will automagically update 

How people get the zips is not our concern, somewhere along the line 
someone must have access to the Internet in order to get Forrest in the 
first plave. They can therefore get the zips using wget or a mnaul 
download process.

Of course, if you have an idea about an even easier process...




View raw message