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 discussed:
(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 empty.
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:
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.