Re: Getting the feeling that we may need a ApacheDS release soon?
On 5/23/11 11:55 AM, Alex Karasulu wrote: On Mon, May 23, 2011 at 12:52 PM, Emmanuel Lecharnywrote: On 5/23/11 11:29 AM, Alex Karasulu wrote: Hi all, With the various posts and bugs people have to work around should we do another release of ApacheDS under the current versioning scheme just to let our users breath easier. I was thinking once we start moving to OSGi we can begin the 2.0-Mx releases but this is taking longer than I had thought. Always seeming to be the case these days for me at least. Regardless of what release label we use I think we need a bug fix release soon. Anyways WDYT? I totally agree with the need of a release asap. We are trying to cut a API 1.0.0-M4 this week, but then, we *must* come back to ADS. The Milestone system seems to fits remarkably well for teh API, I think we should switch to milestone for ADS too. There are too many differences between 1.5.7 and the current trunk (mainly the way we manage the configuration) for our users to deserve an incremented version, IMO. If possible, we could jump to a 2.0.0-M1 at the very beginning of june (may be and of may) and then start incrementally as fast as needed with new milestones, like a M2 for OSGi, a M3 for replication, a M4 for Administrativepoints, etc. Thoughts ? +1 to all points made. Let's start to fix issues that are listed for 2.0.0-M1 then. We have 129 of them, I guess many will be postponed to 2.0.0-M2. This is an exciting time again :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Getting the feeling that we may need a ApacheDS release soon?
On Mon, May 23, 2011 at 12:52 PM, Emmanuel Lecharny wrote: > On 5/23/11 11:29 AM, Alex Karasulu wrote: > >> Hi all, >> >> With the various posts and bugs people have to work around should we do >> another release of ApacheDS under the current versioning scheme just to >> let >> our users breath easier. >> >> I was thinking once we start moving to OSGi we can begin the 2.0-Mx >> releases >> but this is taking longer than I had thought. Always seeming to be the >> case >> these days for me at least. >> >> Regardless of what release label we use I think we need a bug fix release >> soon. Anyways WDYT? >> > I totally agree with the need of a release asap. We are trying to cut a API > 1.0.0-M4 this week, but then, we *must* come back to ADS. > > The Milestone system seems to fits remarkably well for teh API, I think we > should switch to milestone for ADS too. There are too many differences > between 1.5.7 and the current trunk (mainly the way we manage the > configuration) for our users to deserve an incremented version, IMO. > > If possible, we could jump to a 2.0.0-M1 at the very beginning of june (may > be and of may) and then start incrementally as fast as needed with new > milestones, like a M2 for OSGi, a M3 for replication, a M4 for > Administrativepoints, etc. > > Thoughts ? +1 to all points made. Thank, Alex
Re: Getting the feeling that we may need a ApacheDS release soon?
On 5/23/11 11:29 AM, Alex Karasulu wrote: Hi all, With the various posts and bugs people have to work around should we do another release of ApacheDS under the current versioning scheme just to let our users breath easier. I was thinking once we start moving to OSGi we can begin the 2.0-Mx releases but this is taking longer than I had thought. Always seeming to be the case these days for me at least. Regardless of what release label we use I think we need a bug fix release soon. Anyways WDYT? I totally agree with the need of a release asap. We are trying to cut a API 1.0.0-M4 this week, but then, we *must* come back to ADS. The Milestone system seems to fits remarkably well for teh API, I think we should switch to milestone for ADS too. There are too many differences between 1.5.7 and the current trunk (mainly the way we manage the configuration) for our users to deserve an incremented version, IMO. If possible, we could jump to a 2.0.0-M1 at the very beginning of june (may be and of may) and then start incrementally as fast as needed with new milestones, like a M2 for OSGi, a M3 for replication, a M4 for Administrativepoints, etc. Thoughts ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
