Thorsten Scherler wrote:
El mié, 09-08-2006 a las 14:40 +0200, Cyriaque Dupoirieux escribió:
le 09/08/2006 14:29 Ross Gardler a écrit :
[EMAIL PROTECTED] wrote:
Author: cdupoirieux
Date: Wed Aug 9 03:52:50 2006
New Revision: 430032
URL: http://svn.apache.org/viewvc?rev=430032&view=rev
Log:
FOR-812 - Remove skniconf dependency
Add new properties to manage the project name, Url and the rss language.
Add a forrest.properties.xml to site-author to set the project name
and URL...
-1
We need to make a release of the plugin hat is compatible with 0.8
before doing this. The new properties system is not officially
included in the 0.8 release of Forrest.
Having said that, recently the new config system has been seeing more
people using it and it seems t work well, within certain limitations.
Perhaps we should consider including the forrest.properties.xml in the
0.8 release. If this were to happen I could lift my -1 on this commit.
If this were not to happen then this commit must increase the required
Forrest version number within the plugin or in the plugin descriptor
file (but only after a 0.8 compatible release was made).
Just a moment, I have not created the forrest.properties.xml, it was
already there.
Cyriaque,
Yeah, that is right Cyriaque.
As mentioned in an overlapping mail. The only use of the plugins that I
had noticed going through SVN were for experimental features. However,
see below...
Further there are other plugins using the property system (incl. the
projectInfo before this commit).
Only in whiteboard where stability of API is not required.
Ross can you explain why this commit is different to the one that added
properties to default.forrest.properties.xml?
Did previous changes move stable functionality over to using an unstable
properties implementation? If so then I missed the significance of those
changes.
Furthermore, I missed the significance of the addition of new features
that used undocumented/unreleased and untested features of core.
Of course, there is no problem with doing this as long as we have a
release of the plugin at the point at which it was only using stable
features.
We now have a situation where a plugin that claims to be compatible with
0.8 is using features that will not be a part of the 0.8 release. See my
original objects as to why this is a problem, together with my further
responses in other parts of this thread.
Sorry I didn't pick up on this earlier, it only dawned on me when
Cyriaque did the right thing and asked if the community felt his changes
were OK.
Ross
