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
