You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <sa...@soethe.net> on 2005/06/14 10:57:23 UTC
Retirement of docs (Re: New documentation structure, next steps)
> = old dtds that are no longer required for active versions
> (document-v11 and -v12) but might still be wanted on special
> occasions. I'm thinking about having a separate folder or folders
> for these where we move them as a first step of their retirement
> while still keeping them linked before gradually throwing them out
> alltogether.
> Having them in a separate directory makes it easy for people to
> signal their intent of retiring them in the future (by moving them
> there) and allow us to check and clean the folder before each
> release. Deleting a file from here will still be a case-ba-case
> descision of course.
Re: Retirement of docs (Re: New documentation structure, next steps)
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
Juan Jose Pablos a écrit :
> Cyriaque Dupoirieux wrote:
>
>>
>> Just want to add that some dtdV1todtdV2.xsl files already exist in
>> $FORREST_HOME/main/webapp/resources/stylesheets.
>> It could be a good idea to maintain these kind of files in order to
>> migrate old forrest site...
>>
>> For instance, we recently change the skinconf.xsl from v6-3 to v7 and
>> the motd declaration is completly different.
>> A skinconfv63tosxkinconfv70.xsl would have been welcome.
>>
>> WDYT ?
>>
>
> Have a look on main/webapp/resources/stylesheets/upgrade-skinconf.xsl
> it was done for the 0.51 --> 0.6 so I guess that we could use it for
> 0.7 as well...
>
Okay, that's it I suppose.
It is used in site.xml to automatically upgrade the skinconf.xml before
to use it.
I continue to think that this behaviour is interesting and should be
generalized to any DTD - Changes, document, todo...
Cyriaque,
Re: Retirement of docs (Re: New documentation structure, next steps)
Posted by Juan Jose Pablos <ch...@apache.org>.
Cyriaque Dupoirieux wrote:
>
> Just want to add that some dtdV1todtdV2.xsl files already exist in
> $FORREST_HOME/main/webapp/resources/stylesheets.
> It could be a good idea to maintain these kind of files in order to
> migrate old forrest site...
>
> For instance, we recently change the skinconf.xsl from v6-3 to v7 and
> the motd declaration is completly different.
> A skinconfv63tosxkinconfv70.xsl would have been welcome.
>
> WDYT ?
>
Have a look on main/webapp/resources/stylesheets/upgrade-skinconf.xsl
it was done for the 0.51 --> 0.6 so I guess that we could use it for 0.7
as well...
Re: Retirement of docs (Re: New documentation structure, next steps)
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
Just want to add that some dtdV1todtdV2.xsl files already exist in
$FORREST_HOME/main/webapp/resources/stylesheets.
It could be a good idea to maintain these kind of files in order to
migrate old forrest site...
For instance, we recently change the skinconf.xsl from v6-3 to v7 and
the motd declaration is completly different.
A skinconfv63tosxkinconfv70.xsl would have been welcome.
WDYT ?
Cyriaque,
Ferdinand Soethe a écrit :
>Ross Gardler wrote:
>
>
>
>>It is a good idea to clearly mark deprecated DTD's. In fact I would go a
>>step further and say we move them to a deprecatedDTD plugin. This would
>>be an internal plugin. This would leave only active DTD's in core so new
>>users will not be tempted to use deprecated ones.
>>
>>
>
>Certainly worth consideration.
>
>
>
>>However, it is not as simple as it may sound. For example, document1.3
>>extends document 1.2 which extends document 1.1, therefore for document
>>1.3 we need all earlier versions. It would therefore seem that the first
>>step would be to do as you propose, move the earlier DTD's into a
>>deprecated folder and think about the next step later.
>>
>>
>
>Yes, I figured that we have more important issues to program so I took
>a simple solution. Besides, this solution would be more general and
>could also be applied to old howtos such as the one on CVS-SSH.
>(Although we could donate that to projects still using CVS :-))
>
>
>
>--
>Ferdinand Soethe
>
>
>
>
Re: Retirement of docs (Re: New documentation structure, next steps)
Posted by Ferdinand Soethe <sa...@soethe.net>.
Ross Gardler wrote:
> It is a good idea to clearly mark deprecated DTD's. In fact I would go a
> step further and say we move them to a deprecatedDTD plugin. This would
> be an internal plugin. This would leave only active DTD's in core so new
> users will not be tempted to use deprecated ones.
Certainly worth consideration.
> However, it is not as simple as it may sound. For example, document1.3
> extends document 1.2 which extends document 1.1, therefore for document
> 1.3 we need all earlier versions. It would therefore seem that the first
> step would be to do as you propose, move the earlier DTD's into a
> deprecated folder and think about the next step later.
Yes, I figured that we have more important issues to program so I took
a simple solution. Besides, this solution would be more general and
could also be applied to old howtos such as the one on CVS-SSH.
(Although we could donate that to projects still using CVS :-))
--
Ferdinand Soethe
Re: Retirement of docs (Re: New documentation structure, next steps)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>
>>= old dtds that are no longer required for active versions
>> (document-v11 and -v12) but might still be wanted on special
>> occasions. I'm thinking about having a separate folder or folders
>> for these where we move them as a first step of their retirement
>> while still keeping them linked before gradually throwing them out
>> alltogether.
>
>
>> Having them in a separate directory makes it easy for people to
>> signal their intent of retiring them in the future (by moving them
>> there) and allow us to check and clean the folder before each
>> release. Deleting a file from here will still be a case-ba-case
>> descision of course.
It is a good idea to clearly mark deprecated DTD's. In fact I would go a
step further and say we move them to a deprecatedDTD plugin. This would
be an internal plugin. This would leave only active DTD's in core so new
users will not be tempted to use deprecated ones.
However, it is not as simple as it may sound. For example, document1.3
extends document 1.2 which extends document 1.1, therefore for document
1.3 we need all earlier versions. It would therefore seem that the first
step would be to do as you propose, move the earlier DTD's into a
deprecated folder and think about the next step later.
Ross