Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <4D24CF43.90805@apache.org>
Date: Wed, 05 Jan 2011 21:06:27 +0100
From: =?ISO-8859-1?Q?Emmanuel_L=E9charny?= <elecharny@apache.org>
Reply-To: elecharny@apache.org
Organization: The Apache Software Foundation
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [DISCUSS] [Release Scheme] Contract/Policy with users for
 releases
References: <AANLkTi=FHepcTbRFxwEQYzOTXmn3KqaosG826+m0pZMO@mail.gmail.com>
	<4D24B4AC.6080604@gmail.com>
 <AANLkTingdgnmtfa-3UrYt9boeksKA2BoZAnM_rx6=evK@mail.gmail.com>
In-Reply-To: <AANLkTingdgnmtfa-3UrYt9boeksKA2BoZAnM_rx6=evK@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 1/5/11 8:17 PM, Alex Karasulu wrote:
> On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharny<elecharny@gmail.com>wrote:
>
>> On 1/5/11 6:49 PM, Alex Karasulu wrote:
>>
>>> Hi all,
>>>
>>> Let's start off with basics by discussing what our contracts are WRT
>>> API's,
>>> and releases with our users. We can throw out the past focusing on the
>>> future to save time since 2.0 will effectively be a new era.
>>>
>>> This 2.0 release I'm gathering is the first stable, serious, enterprise
>>> ready major release of ApacheDS. 1.0 was kind of a toy considering all
>>> it's
>>> faults and shortcomings so the two situations are not completely the same.
>>>
>>> We have to select a release scheme. Based on the scheme we select, we have
>>> to adhere to the rules of that scheme. This is like picking what our
>>> contract with users of the server will be for release compatibility.
>>>
>>> So when considering compatibility we have to consider several things
>>> besides
>>> just APIs and SPIs:
>>>
>>>    o Database Format
>>>    o Schema
>>>    o Replication Mechanism
>>>    o Configuration
>>>    o API Compatibility
>>>    o Plugins - We have pseudo plugins like Partitions, Interceptors and
>>> Handlers that users can alter which involve SPIs.
>>>
>> I would get the Database Format and Configuration out of the equation. It's
>> up to us to provide tools to migrate from one format to the other. Don't get
>> me wrong : when I say that configuration is out of the equation, I mean that
>> the configuration can change, not its format (ie switching from XML to DIT
>> is possible between to major releases, not between two minor releases).
>>
>>
> Will this be transparent to the user? Meaning can he just upgrade the
> software and the migration will occur without any change in their workflow,
> or anything noticeable in performance, wait time on startup? More
> specifically:
>
> (1) Does the user have to run a tool to migrate from one version to the next
> ?

Definitively, yes.
> (2) If a user has 100 Million entries and there's a migration operation
> running with this take say a few hours to start up the server?
This should be a low level tool, so it should act on the Backend 
interface level
>>   So based the scheme we select we have to define policies for these
>>> interfaces. I am calling anything that is exposed to the users as
>>> interfaces
>>> like DB format for example. We have the following choices for schemes:
>>>
>>> 1. Milestone Scheme (Eclipse)
>>> 2. Traditional major.minor.micro Scheme
>>> 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old
>>> Linux Kernel)
>>> 4. Modern Linux Versioning Scheme
>>>
>>> Se let's start off talking about which scheme we like best and why along
>>> with pros and cons taking into account realistically how we work.
>>>
>> Eclipse uses Milestone to express the fact that they are targeting a major
>> release, and each milestone is one step toward this major release. A
>> milestone can include new features, or API refactoring.
>>
> OK so don't separate development features into different branches. I think
> this is better as well since this stable verses dev branch thing did not
> work so well for us in the past.
>
> People are very familiar with this model as well so there's less to explain.
> Plus eventually when we introduce OSGi into the picture this will serve very
> handy as Jesse pointed out.

Probably, yes.

> My preference goes to :
>> - maj.min.mic where mic are for bug fixes, min are for features additions
>> (and potentially minor API changes) and maj are for large refactoring.
>>
> This is the case for this scheme for the components of the project.
>
>
>> - using Milestone works well when combined with this scheme, for pre-major.
>>
> This is the case for this scheme for the public product version which is a
> group of components, bundles.
>
>
>> - when all the features have been added, RC can be issued
>>
>>
> If we do this can we just follow what Eclipse does exactly instead of adding
> our own customization. It's just nice to reference their way and not have to
> document anything extra. If this RC thing is part of their scheme then lets
> use it.

Attaching to some schema that is already exist, is established and 
undertood by users, then yes. I have the feeling that we are trying to 
reinvent the Version wheel since 0.9...


One more thought I had while commuting back home : the reason I don't 
want to go for a 1.5.8 will vanish if we go for a 2.0-M1 instead.

2.0.M1 will be a clear signal to users that :
- the API may not be stable yet
- the target is definitively 2.0, it's not anymore a continuation of an 
old version (namely 1.5.7)
>> So to summarize :
>>
>> 1.0.0 ->  1.0.1 ->  1.0.2...
>>
>> at any point, we can branch, if some new feature is added or if some minor
>> API refactoring is absolutely needed :
>> 1.1.0 ->  1.1.1 ->  1.1.2 ...
>>
>> When preparing a 2.0.0 :
>> 2.0-M1 ->  2.0-M2 ->  ... 2.0-M5
>>
>> When feature completion and API stabilization is reached :
>> 2.0-M5 ->  2.0-RC1 ->  2.0-RC2 ...
>>
>> When RC have been stabilized and tested, then we can release a major :
>> 2.0-RC5 ->  2.0.0
>>
>> and back to the beginning.
>>
>>
> Hmmm OK I see now the switch from M* to RC* : it's the barrier for stopping
> new features and API changes. OK I like it but is this what these guys do in
> eclipse?
They are producing Milestones (Mx) and Release Candidates (RCx) : 
http://archive.eclipse.org/eclipse/downloads/index.php

I find it clear and easy.


-- 
Regards,
Cordialement,
Emmanuel L�charny
www.iktek.com