cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject [Proposal] Document development/maintenance practices
Date Tue, 09 Mar 2004 15:27:49 GMT
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

View raw message