forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Plugin resolutoin (was Re: [jira] Commented: (FOR-742) trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo)
Date Thu, 05 Apr 2007 10:37:26 GMT
David Crossley wrote:
> Ross Gardler wrote:
>> Ross Gardler (JIRA) wrote:
>>>    [ 
>>> Ross Gardler commented on FOR-742:
>>> ----------------------------------
>>> I've deployed the plugins by manually copying the relevant versioned 
>>> plugins to as the unversioned plugin. 
>> I added these by ssh to then doing copying the files 
>> in /www/* followed by relevant svn add.
>> Am I correct in thinking these changes will make it to the live server 
>> on the next automated update?
> Yes they would be picked up on the next rsync.
> I have a local SVN working copy of forrest/site/ so i do
> such things locally. I didn't think to do it via ssh.
> That should work.
> You should have done an 'svn copy' rather than manual copy
> and then 'svn add'. Also i notice that you haven't done 'svn commit'.

Yes, I should have done copy, not sure why I didn't. As for the commit, 
I tried to, but it wouldn't let me. I assumed that I didn't have the 
permissions because it was going to commit to the public server.

I also should have done it in (as you suggest) as 
this is a read only repo.

I was going from memory. Unfortunately it is faulty, I thought that in 
the past I have done things things here to speed things up. In fact, 
what needs to be done is you do it in the above then do an SVN up from this forces an immediate website update. Serves me 
right for doing it from memory.

I've cleared up this mess now.

> However there are other issues ...
> -----------
> The plugins have been deployed haphazardly over the time
> since the 0.7 release. I was hoping that someone would
> review and deploy each. Then we would follow up with copying
> them to the unversioned space.

This cannot be done without alot of work, and I don't think it is 
necessary. We would have to find the point in SVN that the plugin became 
a 0.8 plugin, roll back to that time and deploy.

Recall that we introduced a two phase aproach recently, deploy and 
release. I don't think we have actually released any plugins recently 
(certainly we have not voted for one).

The deployment/release problem was fixed immediately after we realised 
the problem with the projectInfo plugin, which was the first to be 
upgraded to Forrest 0.8. Since then all deployments have been to the 
correct directoy. Therefore, whatever is in the plugins/0.7 directory is 
a working plugin for 0.7.

> -----------
> I wonder if you done things the wrong way around.
> When we deploy a plugin, it goes into the forrest/site SVN
> at plugins/0.8/ directory.

Not wuite right.

When we deploy, as opposed to release, a plugin it is put into the
plugins root directory (no forrest version number). This plugin version 
has no version number.

When we release it goes into plugins/[FORREST_VERSION]. This version has 
a version number.

So by specifying a plugin version number in we say we 
want a specific plugin version that works on my current Forrest version.

By not specifying a plugin version number we are saying we want the most 
recent plugin that is known to work with my current Forrest version.

I'll explore the significance of this below.

> Also i see a lot of additions in the 0.7 directory. Why?

When we try and retrieve a plugin the order is:

- local plugin
- remote plugin, versioned Forrest
- remote plugin, unversioned forrest

Whether we are looking for a versioned or unversioned plugin depends on 
the settings in

So, lets imagine our Forrest content object specifies an unversioned 
copy of the projectInfo plugin and that the local source files are not 
available. The process is:

- look for local src files [NOT FOUND]
- look for a remote unversioned copy in

Previously this second step would fail since there was no unversioned 
copy in that directory. And so it would progress to the third step:

- look for a remote unversioned copy in

This would succeed, but the plugin would be for forrest version 0.8, and 
would therefore break in 0.7

What I have done is made an unversioned copy of the latest release in 
plugins/o.7 so the second step would succeed.

Why do it this way?

So that we can have development (i.e. none released) versions of plugins 
available for multiple versions of Forrest. This means someone using 
Forrest 0.7 can still work on the plugin without it interfering with the 
latest head development of the plugin. In addition, plugins can have 
independent release cycles for different versions of Forrest. This 
allows a bug to be fixed in a Forrest 0.7 version of a plugin 
independantly of changes in the Forrest 0.8 version.


So, in sumamry. should contain *released* versioned and 
unversioned plugins for Forrest 0.x should contain *deployed* (but not released) 
plugins for Forrest 0.8

This is not the tidiest way of doing things, but currently the download 
mechanism is written as an ANT script and therefore we are limited to 
what is possible (and still readable) in an Ant script. There is an 
issue to rewrite this in Java, but it has not received attention yet and 
may well be superceeded by the 0.9 move Ivy.

> -----------
> Should this action of "copying to the unversioned space"
> have happened at a later stage of the release process?
> I wonder if they are now busted for users of the current
> 0.7 release.

No, it will not affect current users. See explanation above.

In fact this duplication of downloads should be done at plugin release time.


It does need testing to make sure my assumptions and reading of the 
build files are correct.

> -----------
> I see that you don't have your 'umask' set, so now the files
> that you copied have the wrong group permissions and so the
> other committers cannot update.

Really? I've set that in the past. Still I'ce done it again, thanks for 
the heads up. I've also sorted out the SVN status.


View raw message