Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ralph.goers@dslextreme.com
 designates 66.51.199.81 as permitted sender)
Message-ID: <43170AF1.7030807@dslextreme.com>
Date: Thu, 01 Sep 2005 07:06:41 -0700
From: Ralph Goers <Ralph.Goers@dslextreme.com>
Reply-To: rgoers@apache.org
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
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>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit


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!

Just update the Javadoc to say what you want to say. If it isn't 
completely stable yet just try to make sure it doesn't stay that way for 
too long.

>
> 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.

"Internal" to me means that no application should ever use it and that 
it might be removed at a future time.  What you have described is more 
along the lines of "under development" or "in testing".  i.e. use at 
your own risk.

>
> Another solution of course would be to use branches, but this isn't 
> very practical for fine-grained things like outlined above.
>
> Just some thoughts...
>
> Sylvain
>
Ralph