Ross Gardler wrote: > David Crossley wrote: > >I started going through the plugins to fix any major issues > >before the release. > > > >The /plugins/ area of the website has some old *.zip for the > >plugins that have been renamed ... > >OpenOffice.org.zip > >feeder.zip > >htmlArea.zip > >text-output.zip > > > >Should i remove them from the forrest-site/plugins/ SVN? > > Yes, this is something I've been thinking about recently.
Is that "yes remove them" or "ack, i have been wondering too". Being more explicit: I presume that we should remove them rather than deprecate them, because none of them are actually released yet. I say remove and denote in status.xml changes. I will do the Lazy Consensus thing. > The SVN is > going to get into a mess since we update when deploying a plugin but > there is no way to clean it up. We will probably need a periodic tidy > up. I think it should certainly be part of the release process. I agree and would like to discuss this even further. Ross, don't feel that you need to answer straight away, there is still plenty to do on the docs re-org before release. Hopefully some other developers can assist. <aside> While i was developing my first plugin i could spend some time thinking about the process. BTW, thanks, it was so easy to do. There are some issues of duplication that we need to address later, e.g. skinconf and properties that are common to all plugins. Reinhard did some interesting things for Cocoon's docs to define common stuff elsewhere and include it. Later. </aside> The pressing need is to get the plugin infrastructure ready. We need a plan for plugins: naming, versions, releases, distribution, and archiving. If we don't spend time getting this correct now, then we will waste time later. Currently, we are placing pre-releases on the website by adding them to svn:forrest/site/plugins/ and overwiting with files of the same name. I gather that there is the intention to append a -0.7 when we release Forrest, so that there is a definitive version to accompany. We also want to be able to release plugins separately. So perhaps also append -1 then -2 etc. which comes from the version number in plugins/plugins.xml We can also generate an index page from plugins/plugins.xml Now on to the distribution and archiving: Is putting them at f.a.o/plugins/ the ideal? Let's leave it as is for now, but i wonder ... We could distribute the plugins via the normal dist mechanism, so they end up at www.a.o/dist/forrest/ That will also get them automatically archived to archive.apache.org/dist/forrest/ [1] http://www.apache.org/dev/mirrors.html Also, can someone gain ideas from other projects that use plugins: mozilla, maven, --David
