On 5/26/10 8:33 AM, Alex Karasulu wrote:I think that until we reach a point where we have a stable 2.0, we should go for 2.0.0-RC1. Then we can abandon this RC stuff.
On Wed, May 26, 2010 at 4:10 AM, Emmanuel Lecharny<firstname.lastname@example.org>wrote:
Hi guys,Not that I want to push the issue but did we agree to using RCs. I did not
I did my best to cleanup DIR, shared and a bit of API tonite, there are
still some of the associated issue to discuss about.
Regarding DIRSERVER, we have 140 opened issues on 2.0.0-RC1, for 33 fixed.
We also have 2 fixed issues for 1.5.8. We also have 71 opened issues tagged
What about removing the 1.5.8 version, merge all the 2.0.0 issues into
2.0.0-RC1, and move the poms version to 2.0.0-RC1?
get a response to the emails suggesting we just use major.minor.micro
version numbers. If you guys agree to this basic approach then we should
just skip 1.5.8 and push all issues to 2.0.0.
The reason is that we have a hell lot of things to do in order to be production ready for 2.0, including docs and tests (I mean, production tests). We are far from having all those guys finished... Also having a 2.0.0-RC1 will help us to send a message that ADS-2.0-RC1 is finally out there, ready to be tested, and we need feedback. If we release a 2.0 (no RC1) then we might have negative feedback like "it's crap, don't use it !", something we don't want to have for a final version. It *will* take time before we stabilize : remember 1.0-RCs ?
Shared is a bit different beast here. I was even thinking that we should merge shared and the ldap api, as they are the two legs the client and the server will stand. We can release a 0.9.20 and postpone 1.0.0.
Same question for shared, which is currently on 0.9.19, with a 1.0.0-RC1Same logic here as above. Do away with 0.9.20 and push all issues to 1.0.0.
pending : should we get rid of 0.9.20 ?
BTW this means locking down our API in shared which might make life harder
for us since both the server and studio depend on this. Just means we need
to take care of deprecations etc.