forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Williams" <william...@gmail.com>
Subject Re: Managing plugin releases
Date Wed, 26 Jul 2006 13:54:03 GMT
On 7/26/06, Ross Gardler <rgardler@apache.org> wrote:
> Tim Williams wrote:
> > On 7/26/06, Ross Gardler <rgardler@apache.org> wrote:
> >
> >> Tim Williams (JIRA) wrote:
> >> > Discussed here to:
> >> > http://marc.theaimsgroup.com/?t=115257903800001&r=1&w=4
> >> >
> >> > 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) Independent/PMC managed releases
>
> I think that all the code infrastructure for this is in place, all that
> is required is a release process and a user document describing it.

Ok.

> > 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:
http://forrest.apache.org/plugins/
I see only plugin names, not versions.  I would expect to see
org.apache.forrest.plugin.input.excel.v01.zip
org.apache.forrest.plugin.input.excel.v02.zip
org.apache.forrest.plugin.input.excel.v03.zip
or some such.

> > So that users might
> > be able to uninstall v0.3 of a plugin and reinstall 0.2 of a plugin.
>
> Version 0.3 and 0.2 can exist side by side in a single Forrest
> installation, users just need to specify which version they want and
> that's it.
>
> There is currently no way of uninstalling an existing plugin. This might
> be a good idea to save disk space but there is no other reason that I
> can think of where this would be necessary.

True, I guess they just change their forrest properties.

> If we want an uninstall then its just an ant task that is required.
>
> > 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.

The documentation is needed sure, but the point was more that
externally identifiable versioning should exist.

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

> We should also consider distributing the plugins via the mirrors, but
> whilst they are all only a few Kb this is not a major issue.
>
> 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?

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

--tim

Mime
View raw message