directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [Shared] Release plan for 1.0-m1
Date Mon, 07 Feb 2011 17:03:59 GMT
Hi all,

Now with this check pointed merge back to trunks which is about to happen in
15-20 minutes after some super clean, build, test, run of studio etc, we can
release shared 1.0-m1 if y'all like. Here's a release plan that Pierre and I

(0) confirm a stable build in trunk with merge
(1) commit merge back to trunk
(2) assign release manager
(3) modify pom's for new 1.0-m1 version
(4) confirm stability
(5) tag, kick off vote
(6) if vote passes, release
(7) merge back trunk changes with 1.0-m2-SNAPSHOT version into m1
(8) rename m1 branches to m2

In the meantime right after step #1 we can still continue work on stage II
in the m1 branch.


I think we're progressing so rapidly in shared that we might be done and
ready for M1 with all features here in less than 7-10 days. There may be no
point to have more than one milestone release (we can goto RC1 right after
M1) and if this is the case maybe we should push all into M1 in about 7-10
days. This might save our release manager some effort.

Also shared-ldap is messy now. I purified the codec code, and the model,
then moved it out. If you look into the ldap-model and the ldap-codec
modules you'll see that it's much cleaner dependency wise. If you look at
shared-ldap it will look almost empty with what seems a poor organization of
incoherent pieces that remained. This is because what is left here is the
sludge, the toxins, that were extracted from the purified model and codec.
We still need to move these out and make it so the shared-ldap module is

Then we need to make shared ldap into a consolidation jar just like
shared-all but with ONLY what is needed to run as the standard LDAP client
jar. All a user will need is shared-ldap and they have all they need to
connect and go with any ldap server. The shared-ldap module will pull in the
following packages plus dependencies:

    mina dependencies
    commons dependencies

The shared-ldap jar should be the only jar anyone needs to connect and go
with an LDAP server. The API documentation generated from it, the javadocs
will be the ldap API product. We will also have some extras plugin
jars/bundles as optional pieces for ADS specific functionality.

Regardless of the technical points, I think it's still harmless to release
an m1 in its present condition. However I don't think it's very useful with
the status of shared-ldap as it is now. If I don't have to stop working in
the m1 branch (to be renamed m2 after step #1 above) and someone other than
myself wants to deal with being the release manager then they're welcome to
release. I'll cast a +0 on a release vote if all the legal aspects of the
release are in order.


View raw message