directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Date Wed, 05 Jan 2011 18:13:00 GMT
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).
> 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.

Milestone are not exclusive to any other version scheme.

There are also some exotic schemes out there like 
maj.min.mic-alpha/beta/NNN : not anymore frequently use those days. IMO, 
they are more like milestones

It's mainly a question of personal preference here, the idea is to avoid 
bikeshed painting debates.

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.
- using Milestone works well when combined with this scheme, for pre-major.
- when all the features have been added, RC can be issued

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.


> Regards,


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message