From dev-return-77556-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Thu Sep 01 09:41:42 2005 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 84419 invoked from network); 1 Sep 2005 09:41:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Sep 2005 09:41:41 -0000 Received: (qmail 1659 invoked by uid 500); 1 Sep 2005 09:41:38 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 1588 invoked by uid 500); 1 Sep 2005 09:41:38 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 1575 invoked by uid 99); 1 Sep 2005 09:41:38 -0000 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO [127.0.0.1]) (209.237.227.194) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 02:41:36 -0700 Message-ID: <4316CD33.2000809@apache.org> Date: Thu, 01 Sep 2005 11:43:15 +0200 From: Carsten Ziegeler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Releasing 2.1.8, when? References: <4316B698.70208@apache.org> <4316B87A.9000004@nada.kth.se> <4316C6B3.20404@apache.org> In-Reply-To: <4316C6B3.20404@apache.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Sylvain Wallez wrote: > Although I agree with the general principle of shorter release cycles, > we have to define a policy regarding new features introduced in these > frequent releases and the associated contracts. Again, stable / unstable > state, but at a finer intra-block level. > > Let's take an example with the new Location stuff. It's very cool and a > lot of people will want to use it. However, we may not consider the API > totally finished (there are still a few minor changes I'd like to do for > it to be cleaner and more straightforward). What if we make a release > now? The contracts will have changed a bit in the next release! > > So this leads back to a discussion we already had: marking some APIs as > internal, so that people are warned that they should not base their code > on it. The internal status can be used for things that are really > internal (like all the environment handling stuff) and things that are > fully functionnal (i.e. "stable" from a bug point of view) but on which > we still reserve the right to do some modifications. > > Another solution of course would be to use branches, but this isn't very > practical for fine-grained things like outlined above. > Yepp, that's all true and we agreed several times to mark the api, but unfortunately it never happened :( With your location stuff, I think the api changes effect only java developers, so I think we can even release the current state and change things there later on. Now, if we have a fixed schedule (every two months), people know that they have to "finish" new work before the next release and they know when this release will be. This does not solve the problem you describe, but it might lessen it a little bit. Ok, so, what about just marking those new editions with TODO or NOT FINISHED or whatever? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/