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 }
