Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 77210 invoked from network); 24 Jun 2005 18:57:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Jun 2005 18:57:26 -0000 Received: (qmail 63467 invoked by uid 500); 24 Jun 2005 18:57:17 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 63421 invoked by uid 500); 24 Jun 2005 18:57:16 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 63394 invoked by uid 99); 24 Jun 2005 18:57:16 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Jun 2005 11:57:16 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mario@ops.co.at designates 194.152.182.4 as permitted sender) Received: from [194.152.182.4] (HELO smtp.ops.co.at) (194.152.182.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Jun 2005 11:57:17 -0700 Received: by smtp.ops.co.at (Postfix, from userid 65534) id EA82F23C0AC; Fri, 24 Jun 2005 20:57:09 +0200 (CEST) Received: from [192.168.3.1] (mgate.int.ops.co.at [172.27.0.11]) by smtp.ops.co.at (Postfix) with ESMTP id D736623C0AB; Fri, 24 Jun 2005 20:57:06 +0200 (CEST) Message-ID: <42BC578D.5090401@ops.co.at> Date: Fri, 24 Jun 2005 20:57:17 +0200 From: Mario Ivankovits User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List , Jakarta Commons Users List Subject: [VFS][ALL] dependency version handling Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on smtp.ops.co.at X-Spam-Level: X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, hits=-7.2 required=7.0 tests=AWL,BAYES_00,LOCAL_SPAMWORDS, RATWR10_MESSID,SARE_TOCC_USER autolearn=no version=2.64 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi all! I'll try again to discuss it, that times with a more concrete plan. First: Due to the nature of VFS we have a public API (the VFS API) and a private API - the API used to talk to our dependencies. I would like to outline a plan how to deal with release changes: public API: As always, changes which are not backward compatible need two .0 releases. e.g. 1.0 - 2.0 deprecation - 3.0 deletion private API/dependencies: We need a different way for them. A version change which is backward compatible happens silently (in fact I will state them in our release_notes) - no one is forced to go the way with us. More interresting is the part where the version change of a dependency is NOT backward compatible. I propose to start a VOTE at commons-dev and commons-user where we state why we need this upgrade, but allow others to veto it. Other than our common votes I would like to give voting rights to users too. A vote passed if 2/3 of all votes are positive. A negative vote delays its upgrade to the next release (regardless if its a major release) and requires a new VOTE. What do you think? --- Mario --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org