On 1/5/11 8:17 PM, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharny<[email protected]>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
