forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: svn commit: r430032 - in /forrest/trunk: plugins/org.apache.forrest.plugin.input.projectInfo/ plugins/org.apache.forrest.plugin.input.projectInfo/resources/stylesheets/ site-author/
Date Wed, 09 Aug 2006 13:26:05 GMT
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 :
>>> wrote:
>>>>Author: cdupoirieux
>>>>Date: Wed Aug  9 03:52:50 2006
>>>>New Revision: 430032
>>>>FOR-812 - Remove skniconf dependency
>>>>Add new properties to manage the project name, Url and the rss language.
>>>>Add a to site-author to set the project name 
>>>>and URL...
>>>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 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, it was 
>>already there.
> 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

Did previous changes move stable functionality over to using an unstable 
properties implementation? If so then I missed the significance of those 

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 

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.


View raw message