Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 62338 invoked from network); 9 Mar 2004 15:37:09 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Mar 2004 15:37:09 -0000 Received: (qmail 24603 invoked by uid 500); 9 Mar 2004 15:37:01 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 24572 invoked by uid 500); 9 Mar 2004 15:37:00 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 24558 invoked from network); 9 Mar 2004 15:37:00 -0000 Received: from unknown (HELO confixx.bestiole.ch) (66.111.0.243) by daedalus.apache.org with SMTP; 9 Mar 2004 15:37:00 -0000 Received: from apache.org (lsn-boi-catv-c121-p001.vtx.ch [212.147.121.1]) by confixx.bestiole.ch (8.11.6/8.11.6) with ESMTP id i29FaxP00339 for ; Tue, 9 Mar 2004 16:36:59 +0100 Date: Tue, 9 Mar 2004 16:37:05 +0100 Subject: Re: [Proposal] Document development/maintenance practices Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Bertrand Delacretaz To: dev@cocoon.apache.org Content-Transfer-Encoding: quoted-printable In-Reply-To: <20040309152749.GD24612@keow.org> Message-Id: <9E7E87B6-71DF-11D8-B5A4-000393CFE402@apache.org> X-Mailer: Apple Mail (2.553) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Le Mardi, 9 mars 2004, =E0 16:27 Europe/Zurich, Tim Larson a =E9crit : > ...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