So, I revert my commit to be able to make a release of projectInfo ?
(And I will re-commit latter.)
Ok ?
Salutations,
Cyriaque,
And sorry for the noise :-( .
le 09/08/2006 15:26 Ross Gardler a écrit :
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
