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
