Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43EF48D2.8090408@apache.org>
Date: Sun, 12 Feb 2006 14:40:18 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: deployed plugins with wrong version number
References: <4375D0A0.7040502@apache.org>
 <20051113084052.GA9667@igg.indexgeo.com.au> <437710F3.2030509@apache.org>
 <20051114102321.GA12951@igg.indexgeo.com.au> <4378735F.8070108@apache.org>
 <20051125064839.GA5260@igg.indexgeo.com.au> <4386EC77.5040507@apache.org>
 <20051126011510.GB6703@igg.indexgeo.com.au> <4387FBB6.2070301@apache.org>
 <20060211073039.GA11514@igg.indexgeo.com.au>
 <20060212031334.GA15711@igg.indexgeo.com.au>
In-Reply-To: <20060212031334.GA15711@igg.indexgeo.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Crossley wrote:
> David Crossley wrote:
> 
>>Reviving this old thread from Nov 26, 2005.
>>
>>At today's ForrestFriday we discussed the issue
>>again. See the IRC logfile.
>>http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt
>>
>>Ross, i figured out some of my confusion about this.
>>I did not realise that there are two separate targets
>>"deploy" and "release".
>>
>>Please review this revision which i think fixes the deployment.
>>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/build.xml?rev=376952&r1=376890&r2=376952&diff_format=h
>>
>>Next we need to investigate the fetch-plugin stuff,
>>then deploy all relevant plugins.
> 
> 
> Hmmm, i reckon that this is not going to work.
> For example, the projectInfo input plugin.
> 
> We recently upgraded that plugin to use locationmap,
> so now it is bound to forrest-0.8 version.
> That is now deployed as the top-level unversioned
> f.a.o/plugins/o.a.f.plugin.projectInfo.zip
> 
> So now forrest-0.7 users need to specifically declare
> the versioned plugin which forrest-0.7 will find at
> f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
> 
> Perhaps the following arrangement would be better:
> 
> Deploy both versioned and unversioned plugins to
> the respective forrest.version directory, i.e.
> 
> f.a.o/plugins/0.7/o.a.f.plugin.projectInfo.zip
> f.a.o/plugins/0.7/o.a.f.plugin.projectInfo-0.1.zip
> ...
> f.a.o/plugins/0.8/o.a.f.plugin.projectInfo.zip
> f.a.o/plugins/0.8/o.a.f.plugin.projectInfo-0.2.zip
> ...
> 
> Don't use the top-level f.a.o/plugins/*.zip at all.

But this would mean deploying the unversioned copy to all the forrest 
core version directories, i.e. 0.7, 0.8. 0.9, 0.10 etc.

A little reminder form our IRC chat:

The idea of the unversioned plugins is that a user can say "I want to be 
at the cutting edge of this particular plugin, but I don't care about 
the core of Forrest".

These people specify an unversioned plugin, Forrest will download the 
latest development version of the plugin (it is intended that a later 
version of Forrest will automatically upgrade this plugin to keep the 
user on the cutting edge).

So, a user using Forrest 0.7 will get the same version the projectInfo 
plugin as one using Forrest 0.8 (i.e. from the top level directory). 
But, what if the latest dev plugin doesn't work with their installed 
version of Forrest?

At this point Forrest should report that they need to upgrade Forrest in 
order to work with the latest projectInfo plugin, or they will need to 
downgrade the plugin version to the last version working with 0.7 
(eventually Forrest should ask what to do and update the properties file 
appropriately).

We can do swanky things like list the improvements in Forrest and the 
Plugin to help users make this decision, but that is for later too.

Ross