David Crossley wrote:
Ross Gardler wrote:
Ross Gardler (JIRA) wrote:
[
https://issues.apache.org/jira/browse/FOR-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486778 ]
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 people.apache.org then doing copying the files
in /www/forrest.apache.org/plugins/* 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.
http://www.apache.org/dev/project-site.html
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
http://svn.apache.org/repos/asf/forrest/site/plugins (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
people.apache.org. 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 forrest.properties 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 forrest.properties.
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 forrest.apache.org/plugins/0.7/
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 forrest.apache.org/plugins
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.
forrest.apache.org/plugins/0.x should contain *released* versioned and
unversioned plugins for Forrest 0.x
forrest.apache.org/plugins 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.
BUT...
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.
http://www.apache.org/dev/new-committers-guide.html#shell
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.
Ross
