Johannes Schaefer wrote:
Ross Gardler schrieb:
Johannes Schaefer wrote:
Do these changes get back to the downloadable version?
http://forrest.apache.org/mirrors.cgi#closest
First of all, the plugins are not downloaded via the mirrors (this is
something that we need to address at some point, but this is not too
urgent since the plugins are typically very small).
Secondly, plugins have a different release cycle from Forrest core. So
these changes will only make it into the distributed version when we
make a release of the plugin.
Just to understand: if I'll break forrest 0.7 with a change to some
plugin I'll need to create a new version of it?
I just added the following FAQ response to [1] (documenting as I go):
What if a new feature breaks compatability with a released version of
Forrest?
------------------------------------------------------------------------------
If you add a feature to a plugin that will break compatability with a
released version of Forrest then you should up the forrest version
number in the plugins build.xml file. This will prevent the new version
of the plugin being made avialble to the older version of
Forrest.
However, you might light to consider doing a release of the plugin
before you break compatability. It depends on what other changes there
are to the plugin before you start your work. It is always best to raise
this on the dev list.
How do we make a release? We're still in the process of specifying this.
However, it will be essentially the same as a release for core, i.e.
someone proposes it for a release, we vote, we release or not according
to the vote.
I've seen some of the discussion.
We'll need to relate the plugins to (released) versions of forrest.
That is already done (see forrest version number in plugins build.xml)
However, it can still be used without a release. Let me explain.
The current version of SVN head doesn't use plugins in-place yet. But
what it does do is deploy the plugins from local src directories if they
are not currently installed and no version number is provided for the
plugin in forrest.properties.
In addition, we can release unversioned copies of the plugin, which will
then be installed to those users without the src. However, this is the
part of the release process we have not yet fully worked out.
So, what do you want to achieve? Continue the discussion down whichever
of the above avenues you need to, lets work out the relevant process.
We use forrest at customer's sites and I simply would like to point
them to the download page and say: get the latest release (update).
It's hard talking them into svn and stuff :-)
If no vbersion number is supplied Forrest will always, automatically,
download the most recent version of the plugin for the version of
Forrest being run.
However, you should be aware that this may be a development version as
things currently stand. I have been thinking of changing the behaviour
slightly, so that if no version is specified the most recent *released*
version is installed, if "-dev" is specified then the most recent
development version is specified.
There is no need for the user to download anything. Forrest will do that
automatically (unless there is an issue with write permissions or proxies).
So, are the updates to the released forrest-0.7 brought back to the
binary distribution at http://forrest.apache.org/mirrors.cgi ?
As far as I see: No.
No, as I said before, the plugins are not mirrored. They are only
available from the plugin download site [2], Forrest *automatically*
retrieves them from there (but note, they are not upgraded
automatically, the user has to delete the installed plugins for the
upgrade to occur - another todo item [3]).
To get plugins onto the plugin site it must be deployed. However, when
and how we can do this has not yet been fully agreed.
I just changed the plugin build system slightly. It is now possible to
deploy a plugin or to release it. Deploying only uploads the
unversioned, i.e. development, copy to the download server. Releasing
uploads a versioned copy.
This means that you can now safely do "ant deploy" for the docbook plugin.
You update will be used by 0.7 Forrest (assuming that you have not
broken backward compatability and therefore not updated the minimum
Forrest version number). To have your clients update all they need to do
is delete FORREST_HOME/build/plugins/PLUGIN_NAME and run Forrest as normal.
I hope this is getting clearer to us all, me included ;-)
Ross
[1]
http://svn.apache.org/repos/asf/forrest/trunk/plugins/RELEASE_PROCESS.txt
[2] http://forrest.apache.org/plugins/
[3] http://issues.apache.org/jira/browse/FOR-343
