You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Larson <ti...@keow.org> on 2004/03/09 16:27:49 UTC
[Proposal] Document development/maintenance practices
At my workplace they are worried that pairing their slow upgrade
cycle with the fast pace of open source projects could cause
maintenance problems for their custom code. They are concerned
that a delayed upgrade may be as painful as switching to another
project. I propose we create a document detailing the practices
and policies we follow to minimize this risk to users of Cocoon.
To start the discussion, here is a seed list of practices that
I have noticed we try to be known for following:
[Disclaimer: We are under no contract and offer no warranty
concerning these practices (see our license for details.)]
Continuing to support older releases
Maintaining a change log to help with upgrades
Strongly avoiding breaking interfaces
Conducting open, public discussion of design and development
Querying userbase to determine impact of potential changes
Responding to the userbase, even reverting changes when necessary
Voting on major additions, changes, deprecations, and removals
Deprecating interfaces instead of immediately dropping support
Only allowing code that has a community to support it
What do others think about developing a document like this
to document our guidelines and improve our marketability?
Do we already have a document like this somewhere?
--Tim Larson
Re: [Proposal] Document development/maintenance practices
Posted by Antonio Gallardo <ag...@agssa.net>.
Tim Larson dijo:
> At my workplace they are worried that pairing their slow upgrade
> cycle with the fast pace of open source projects could cause
> maintenance problems for their custom code. They are concerned
> that a delayed upgrade may be as painful as switching to another
> project. I propose we create a document detailing the practices
> and policies we follow to minimize this risk to users of Cocoon.
>
> To start the discussion, here is a seed list of practices that
> I have noticed we try to be known for following:
>
> [Disclaimer: We are under no contract and offer no warranty
> concerning these practices (see our license for details.)]
>
> Continuing to support older releases
> Maintaining a change log to help with upgrades
> Strongly avoiding breaking interfaces
> Conducting open, public discussion of design and development
> Querying userbase to determine impact of potential changes
> Responding to the userbase, even reverting changes when necessary
> Voting on major additions, changes, deprecations, and removals
> Deprecating interfaces instead of immediately dropping support
> Only allowing code that has a community to support it
>
> What do others think about developing a document like this
> to document our guidelines and improve our marketability?
> Do we already have a document like this somewhere?
+1. Good idea, it can be stated as "official" project practices. It wil
help to reduce the FUD.
Best Regards,
Antonio Gallardo
Sample slide block download/view problem with cocoon 2.1.4
Posted by jp...@quoininc.com.
I've been unsuccessful in getting the slide block sample to work.
I'm able to authenticate, upload files, and browse the repository.
When I try to view a file, it always fails with the error message
"Could not display content".
Part of the problem is the stylesheet content content2html.xsl does
not see have a value for mime-type.
Anyone have success getting slide working?
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Proposal] Document development/maintenance practices
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>At my workplace they are worried that pairing their slow upgrade
>cycle with the fast pace of open source projects could cause
>maintenance problems for their custom code. They are concerned
>that a delayed upgrade may be as painful as switching to another
>project. I propose we create a document detailing the practices
>and policies we follow to minimize this risk to users of Cocoon.
>
>To start the discussion, here is a seed list of practices that
>I have noticed we try to be known for following:
>
> [Disclaimer: We are under no contract and offer no warranty
> concerning these practices (see our license for details.)]
>
> Continuing to support older releases
> Maintaining a change log to help with upgrades
> Strongly avoiding breaking interfaces
> Conducting open, public discussion of design and development
> Querying userbase to determine impact of potential changes
> Responding to the userbase, even reverting changes when necessary
> Voting on major additions, changes, deprecations, and removals
> Deprecating interfaces instead of immediately dropping support
> Only allowing code that has a community to support it
>
>What do others think about developing a document like this
>to document our guidelines and improve our marketability?
>Do we already have a document like this somewhere?
>
>
Sounds very good, and a useful addition to our documentation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Proposal] Document development/maintenance practices
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 9 mars 2004, à 16:27 Europe/Zurich, Tim Larson a écrit :
> ...I propose we create a document detailing the practices
> and policies we follow to minimize this risk to users of Cocoon.
Sounds good.
> ... Maintaining a change log to help with upgrades
And our CVS has all the details
> Strongly avoiding breaking interfaces
And indicating what's more stable or more subject to change
> Conducting open, public discussion of design and development
> Querying userbase to determine impact of potential changes
> Responding to the userbase, even reverting changes when necessary
> Voting on major additions, changes, deprecations, and removals
> Deprecating interfaces instead of immediately dropping support
> Only allowing code that has a community to support it
>
> What do others think about developing a document like this
> to document our guidelines and improve our marketability?
I like the idea, maybe you can start something on the wiki?
> Do we already have a document like this somewhere?
I don't think so.
-Bertrand