You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2010/05/23 07:10:14 UTC
[ApacheDS] Release versioning scheme.
On Sat, May 22, 2010 at 5:21 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> On 5/22/10 4:02 PM, Kiran Ayyagari wrote:
>
>> May be this is also the time for considering the new versioning
>
> scheme[1] we discussed last year
>>
>>
> Absolutely. We should stop using a versioning scheme that is confusing for
> most of us, and more important, to users.
>
> The intial reason why we introduced this scheme ws tha we decided to move
> to Java 1.5, and we thought (how stupidly) that the tomcat scheme (ie,
> tomcat 5.5 was tomcat version 5 for java 5) was good. It wasn't.
>
>
Yeap in hind sight it was a bad move.
> So now, I would rather release a 2.0 asap, with milestone. The ne version
> will be 3.0, with milestone too.
>
> In fact, this is the Httpd version scheme, which is way better. New
> features can be included in minor versions (2.1, 2.2...) and bug fixes in
> fix versions (2.0.1, 2.0.2...)
>
>
Yes this scheme is much more appealing. However I'm not into this milestone
designation. I don't really see the point (perhaps someone might show me in
this thread). Let me explain my thinking below.
To me you either have a release or you don't release. With the httpd scheme
above you have no need for milestone releases because 2.0.0, 2.1.0, 2.2.0
... X.Y.0 are milestones in that they introduce new features. Hence the
minor bump. The micro releases are just bug fix releases that do not
introduce new features after the minor ("milestone") release. So this is why
this httpd scheme does not need M1, M2 .. a la eclipse style releases.
The next thing we need to talk about is what the major, minor and mico
releases signify to our users. Here's how I look at it in terms of our user
agreement:
o major releases do not guarantee interoperability out of the box since
internal and external interfaces, db formats, and the entire architecture
may change
o minor releases guarantee interoperability, interface integrity, db
format consistency across releases with architectural stability. New
features may be introduced and some features may be enhanced.
o micro releases are simple bug fix releases which do not introduce
anything new
Thoughts?
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [ApacheDS] Release versioning scheme.
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, May 24, 2010 at 11:14 AM, Stefan Seelmann <se...@apache.org>wrote:
> Hi Alex,
>
> I don't insist on those milestone releases. I just find them useful in
> this case to be able to release fast, even if not everything is
> finished, and to avoid that users think everything is polished.
>
>
Right I know what you mean. There's I guess no guarantee for stability
although the product release may very well be stable with a milestone
release. The key thing here is how we want to formulate our contract with
our users while we release and what cues we give them with our version
numbering scheme.
You're right that this is not a major issue (bike shedding): either scheme
will work. I'm just in preference of simple numbers without designators.
Let's release fast and release often and let the community know that minor
releases in the same major release represents feature additions that don't
break with the past. Subsequent micro releases may patch and stabilize
these features.
> Anyway, I totally agree with all your other points. So let's go on.
>
>
Cool.
> Kind Regards,
> Stefan
>
>
> Alex Karasulu wrote:
> >
> >
> > On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <seelmann@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Alex Karasulu wrote:
> > > Yes this scheme is much more appealing. However I'm not into this
> > > milestone designation. I don't really see the point (perhaps
> someone
> > > might show me in this thread). Let me explain my thinking below.
> > >
> > > To me you either have a release or you don't release. With the
> httpd
> > > scheme above you have no need for milestone releases because 2.0.0,
> > > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
> >
> > No sure about that, httpd released a 2.3.5-alpha
> >
> >
> > Hmmm OK I didn't know that. Regardless though I think the designation is
> > unnecessary. The new minor release number inherently represents
> > something that has changed by adding new features which may destabilize
> > the software. We don't really know how much and if that amount means
> > give it an alpha flag. How alpha is alpha?
> >
> > Plus with certain tooling this -alpha designator might be an issue. Why
> > bother dealing with the risk?
> >
> >
> > > features. Hence the minor bump. The micro releases are just bug
> fix
> > > releases that do not introduce new features after the minor
> > > ("milestone") release. So this is why this httpd scheme does not
> need
> > > M1, M2 .. a la eclipse style releases.
> >
> > I think milestones can be used to indicate that we are on the way to
> > 2.0, but it's not ready yet.
> >
> >
> > I'm still not convinced of this technique. I know eclipse uses this but
> > it's not very appealing to me. I prefer the new Linux kernel scheme
> > which fits what I spoke of in the block above.
> >
> >
> > As Emmanuel wrote, we have several tasks to do:
> > - documentation of the new features
> > - update the current documentation
> > - update the examples
> > - tooling
> > - bug fixing
> > - renew Open Group certification?
> > I'm in doubt we can do this within 3 weeks.
> >
> >
> > Well no matter how long that might take people can still build the
> > server if they like and we should have nightly builds available for
> > testing between these periods. I was a +1 on the switch from doing 1.5.x
> > builds to starting to bring forth a 2.0.
> >
> >
> > An M1 could indicate to our users: hey, ApacheDS now supports RFC
> 4533
> > replication and CiDIT. Help to test it. Test interoperability with
> > OpenLDAP. Provide feedback.
> >
> >
> > I think we should just release the 2.0.0 in 3 weeks and let people go
> > wild with it.
> >
> >
> > And for us it indicates: no more big-bang refactoring till 2.0 GA,
> but
> > we can still modify API during bug fixing.
> >
> >
> > The same fits for a 2.0.1 ... 2.0.*. I think we should keep things
> > simple here. Just because some projects use this M* scheme that does not
> > mean we should too.
> >
> >
> >
> > > The next thing we need to talk about is what the major, minor and
> mico
> > > releases signify to our users. Here's how I look at it in terms
> > of our
> > > user agreement:
> > >
> > > o major releases do not guarantee interoperability out of the box
> > > since internal and external interfaces, db formats, and the entire
> > > architecture may change
> > > o minor releases guarantee interoperability, interface integrity,
> db
> > > format consistency across releases with architectural stability.
> New
> > > features may be introduced and some features may be enhanced.
> > > o micro releases are simple bug fix releases which do not
> introduce
> > > anything new
> >
> > +1
> >
> > Kind Regards,
> > Stefan
> >
> >
> >
> >
> >
> > --
> > Alex Karasulu
> > My Blog :: http://www.jroller.com/akarasulu/
> > Apache Directory Server :: http://directory.apache.org
> > Apache MINA :: http://mina.apache.org
> > To set up a meeting with me: http://tungle.me/AlexKarasulu
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [ApacheDS] Release versioning scheme.
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, May 24, 2010 at 12:17 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Hi guys,
>
> I didn't had time to rply to Alex' mail. Here it is :
>
>
> On 5/24/10 10:14 AM, Stefan Seelmann wrote:
>
>> Hi Alex,
>>
>> I don't insist on those milestone releases. I just find them useful in
>> this case to be able to release fast, even if not everything is
>> finished, and to avoid that users think everything is polished.
>>
>> Anyway, I totally agree with all your other points. So let's go on.
>>
>> Kind Regards,
>> Stefan
>>
>>
>> Alex Karasulu wrote:
>>
>>
>>>
>>> On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann<seelmann@apache.org
>>> <ma...@apache.org>> wrote:
>>>
>>> Alex Karasulu wrote:
>>> > Yes this scheme is much more appealing. However I'm not into this
>>> > milestone designation. I don't really see the point (perhaps
>>> someone
>>> > might show me in this thread). Let me explain my thinking below.
>>> >
>>> > To me you either have a release or you don't release. With the
>>> httpd
>>> > scheme above you have no need for milestone releases because
>>> 2.0.0,
>>> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
>>>
>>> No sure about that, httpd released a 2.3.5-alpha
>>>
>>>
>>> Hmmm OK I didn't know that. Regardless though I think the designation is
>>> unnecessary. The new minor release number inherently represents
>>> something that has changed by adding new features which may destabilize
>>> the software. We don't really know how much and if that amount means
>>> give it an alpha flag. How alpha is alpha?
>>>
>>> Plus with certain tooling this -alpha designator might be an issue. Why
>>> bother dealing with the risk?
>>>
>>>
>> We can either go for Milestone or Minor versions. That does not make a lot
> of difference to me. The only big difference from the user perspective is
> that Milestone are more or less seen as not production ready. This is the
> way Eclipse work, but they have a much strict roadmap, something we don't
> have.
>
Yes we don't have a solid/strict road map but if we presume we do the minor
versions can be used in place of milestones. With minor versions
representing feature introductions we're not saying *explicitly* it might
not be as stable as we want it to be. Instead we are saying something more
like, hey look, this minor release introduces these *new* features. We gave
it our best shot so you (our users) can use it and got it out fast to the
users for testing. If there are issues we'll fix those issues in micro
releases.
We're giving it our best shot to be stable but *implicitly* we're saying it
may be patched with micro releases in the future and this is OK IMO.
> </snip>
>>>
>>>
>>> I think we should just release the 2.0.0 in 3 weeks and let people go
>>> wild with it.
>>>
>>>
>> I don't favor this option though. We will have major refactoring if we
> release what we have as a 2.0. Here, the message will be : "eh, guys, we are
> ready" when we are not. I would rather go for a 2.0-RC1 like we did for 1.0,
> as we had many opportunities to fix many serious issues.
>
>
I think we can go either way. It's only a matter of how we look at it. As
you probably remember I was a fan of RCs before. I now feel I was being a
bit rigid. We can lock in the code and do a bunch of RCs to stabilize or we
can come out with 2.0.0 and come out with micro releases. NOTE: once we
enter the RC release phase we cannot change interfaces anymore just like
when we enter 2.0.0. The RC just translates to more stabilizing micro
releases on 2.0. Plus I'm starting to think all these designators are really
not helping us. Simple and easy is best.
Also unless the software is put into the wild without stigma, some problems
will not arise, so they can be fixed fast. The key is to fix the issues
without breaking back compatibility so users can upgrade fast without db
changes or code changes. Just reinstalling the software will bring them up
to date removing issues and this is acceptable.
Also I remember a great email conversation almost 7 years ago on another
project's mailing list. It was agreed that releasing fast and releasing
often was more important than making sure the code was absolutely stable.
Firstly because you can never really be absolutely stable and second because
only life in the wild will show if the code is fit enough: fixing sometimes
what you think is the big issue does not really fix the big problems in the
wild. Third and most important was the idea that stability is not that
important. Yeah you heard me right. Just get the feature out and let the
user community report the problems so you can fix it fast but fix it fast
and release fast. This keeps the user community more involved with the
project and communicating with us. It's actually the best way to keep a
vibrant community and spend less time testing/improving something which you
really cannot tell is broken. You only know in the wild. I'm not saying
write and release buggy software and nor were these guys saying this. I'm
saying let's fear not providing stability on the first major release. If we
blindly stick to the release early release often strategy and communicate
with our users, then eventually we will converge towards stability with the
least testing effort and the greatest gain in community. So let's make sure
we get the releases out fast to fix the issues that arise for our users when
they contact us with problems. This way we can stimulate a more vibrant user
community while allowing us to focus more time in the right places
developing rather than testing.
BTW my only worry with this scheme of major.minor.micro is what if we find a
bug that requires extensive changes to the code that breaks with back
compatibility? I have not figured out how the release scheme can manage
this. Thoughts?
Is it suitable to bump to the next major release number if
back compatibility needs to be broken?
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [ApacheDS] Release versioning scheme.
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi guys,
I didn't had time to rply to Alex' mail. Here it is :
On 5/24/10 10:14 AM, Stefan Seelmann wrote:
> Hi Alex,
>
> I don't insist on those milestone releases. I just find them useful in
> this case to be able to release fast, even if not everything is
> finished, and to avoid that users think everything is polished.
>
> Anyway, I totally agree with all your other points. So let's go on.
>
> Kind Regards,
> Stefan
>
>
> Alex Karasulu wrote:
>
>>
>> On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann<seelmann@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Alex Karasulu wrote:
>> > Yes this scheme is much more appealing. However I'm not into this
>> > milestone designation. I don't really see the point (perhaps someone
>> > might show me in this thread). Let me explain my thinking below.
>> >
>> > To me you either have a release or you don't release. With the httpd
>> > scheme above you have no need for milestone releases because 2.0.0,
>> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
>>
>> No sure about that, httpd released a 2.3.5-alpha
>>
>>
>> Hmmm OK I didn't know that. Regardless though I think the designation is
>> unnecessary. The new minor release number inherently represents
>> something that has changed by adding new features which may destabilize
>> the software. We don't really know how much and if that amount means
>> give it an alpha flag. How alpha is alpha?
>>
>> Plus with certain tooling this -alpha designator might be an issue. Why
>> bother dealing with the risk?
>>
We can either go for Milestone or Minor versions. That does not make a
lot of difference to me. The only big difference from the user
perspective is that Milestone are more or less seen as not production
ready. This is the way Eclipse work, but they have a much strict
roadmap, something we don't have.
>> </snip>
>>
>> I think we should just release the 2.0.0 in 3 weeks and let people go
>> wild with it.
>>
I don't favor this option though. We will have major refactoring if we
release what we have as a 2.0. Here, the message will be : "eh, guys, we
are ready" when we are not. I would rather go for a 2.0-RC1 like we did
for 1.0, as we had many opportunities to fix many serious issues.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [ApacheDS] Release versioning scheme.
Posted by Alex Karasulu <ak...@apache.org>.
On Mon, May 24, 2010 at 11:46 AM, Felix Knecht <fe...@apache.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/24/10 10:14, Stefan Seelmann wrote:
> > Hi Alex,
> >
> > I don't insist on those milestone releases. I just find them useful in
> > this case to be able to release fast, even if not everything is
> > finished, and to avoid that users think everything is polished.
> >
> > Anyway, I totally agree with all your other points. So let's go on.
>
>
> No matter which schema we use in the end, IMO we should choose a schema
> fitting the version number rules of maven [1].
>
Yeah I was thinking of this while I wrote my email and various OSGi tools
link bnd and their Maven Plugin. I know there were some issues before but
they must have been resolved. Either way I just want to be super safe.
-Alex
>
> My 2 cents
> Felix
>
> [1] http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
>
>
> >
> > Kind Regards,
> > Stefan
> >
> >
> > Alex Karasulu wrote:
> >>
> >>
> >> On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <seelmann@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> Alex Karasulu wrote:
> >> > Yes this scheme is much more appealing. However I'm not into this
> >> > milestone designation. I don't really see the point (perhaps
> someone
> >> > might show me in this thread). Let me explain my thinking below.
> >> >
> >> > To me you either have a release or you don't release. With the
> httpd
> >> > scheme above you have no need for milestone releases because
> 2.0.0,
> >> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
> >>
> >> No sure about that, httpd released a 2.3.5-alpha
> >>
> >>
> >> Hmmm OK I didn't know that. Regardless though I think the designation is
> >> unnecessary. The new minor release number inherently represents
> >> something that has changed by adding new features which may destabilize
> >> the software. We don't really know how much and if that amount means
> >> give it an alpha flag. How alpha is alpha?
> >>
> >> Plus with certain tooling this -alpha designator might be an issue. Why
> >> bother dealing with the risk?
> >>
> >>
> >> > features. Hence the minor bump. The micro releases are just bug
> fix
> >> > releases that do not introduce new features after the minor
> >> > ("milestone") release. So this is why this httpd scheme does not
> need
> >> > M1, M2 .. a la eclipse style releases.
> >>
> >> I think milestones can be used to indicate that we are on the way to
> >> 2.0, but it's not ready yet.
> >>
> >>
> >> I'm still not convinced of this technique. I know eclipse uses this but
> >> it's not very appealing to me. I prefer the new Linux kernel scheme
> >> which fits what I spoke of in the block above.
> >>
> >>
> >> As Emmanuel wrote, we have several tasks to do:
> >> - documentation of the new features
> >> - update the current documentation
> >> - update the examples
> >> - tooling
> >> - bug fixing
> >> - renew Open Group certification?
> >> I'm in doubt we can do this within 3 weeks.
> >>
> >>
> >> Well no matter how long that might take people can still build the
> >> server if they like and we should have nightly builds available for
> >> testing between these periods. I was a +1 on the switch from doing 1.5.x
> >> builds to starting to bring forth a 2.0.
> >>
> >>
> >> An M1 could indicate to our users: hey, ApacheDS now supports RFC
> 4533
> >> replication and CiDIT. Help to test it. Test interoperability with
> >> OpenLDAP. Provide feedback.
> >>
> >>
> >> I think we should just release the 2.0.0 in 3 weeks and let people go
> >> wild with it.
> >>
> >>
> >> And for us it indicates: no more big-bang refactoring till 2.0 GA,
> but
> >> we can still modify API during bug fixing.
> >>
> >>
> >> The same fits for a 2.0.1 ... 2.0.*. I think we should keep things
> >> simple here. Just because some projects use this M* scheme that does not
> >> mean we should too.
> >>
> >>
> >>
> >> > The next thing we need to talk about is what the major, minor and
> mico
> >> > releases signify to our users. Here's how I look at it in terms
> >> of our
> >> > user agreement:
> >> >
> >> > o major releases do not guarantee interoperability out of the
> box
> >> > since internal and external interfaces, db formats, and the entire
> >> > architecture may change
> >> > o minor releases guarantee interoperability, interface
> integrity, db
> >> > format consistency across releases with architectural stability.
> New
> >> > features may be introduced and some features may be enhanced.
> >> > o micro releases are simple bug fix releases which do not
> introduce
> >> > anything new
> >>
> >> +1
> >>
> >> Kind Regards,
> >> Stefan
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Alex Karasulu
> >> My Blog :: http://www.jroller.com/akarasulu/
> >> Apache Directory Server :: http://directory.apache.org
> >> Apache MINA :: http://mina.apache.org
> >> To set up a meeting with me: http://tungle.me/AlexKarasulu
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkv6PM8ACgkQ2lZVCB08qHEINACfalg/ibbued1W8wtGnE/ZKMJ5
> KA4Amwcb+JGwV8d+gSJJcTm4iwTngkmh
> =C1EQ
> -----END PGP SIGNATURE-----
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [ApacheDS] Release versioning scheme.
Posted by Felix Knecht <fe...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/24/10 10:14, Stefan Seelmann wrote:
> Hi Alex,
>
> I don't insist on those milestone releases. I just find them useful in
> this case to be able to release fast, even if not everything is
> finished, and to avoid that users think everything is polished.
>
> Anyway, I totally agree with all your other points. So let's go on.
No matter which schema we use in the end, IMO we should choose a schema
fitting the version number rules of maven [1].
My 2 cents
Felix
[1] http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
>
> Kind Regards,
> Stefan
>
>
> Alex Karasulu wrote:
>>
>>
>> On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <seelmann@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Alex Karasulu wrote:
>> > Yes this scheme is much more appealing. However I'm not into this
>> > milestone designation. I don't really see the point (perhaps someone
>> > might show me in this thread). Let me explain my thinking below.
>> >
>> > To me you either have a release or you don't release. With the httpd
>> > scheme above you have no need for milestone releases because 2.0.0,
>> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
>>
>> No sure about that, httpd released a 2.3.5-alpha
>>
>>
>> Hmmm OK I didn't know that. Regardless though I think the designation is
>> unnecessary. The new minor release number inherently represents
>> something that has changed by adding new features which may destabilize
>> the software. We don't really know how much and if that amount means
>> give it an alpha flag. How alpha is alpha?
>>
>> Plus with certain tooling this -alpha designator might be an issue. Why
>> bother dealing with the risk?
>>
>>
>> > features. Hence the minor bump. The micro releases are just bug fix
>> > releases that do not introduce new features after the minor
>> > ("milestone") release. So this is why this httpd scheme does not need
>> > M1, M2 .. a la eclipse style releases.
>>
>> I think milestones can be used to indicate that we are on the way to
>> 2.0, but it's not ready yet.
>>
>>
>> I'm still not convinced of this technique. I know eclipse uses this but
>> it's not very appealing to me. I prefer the new Linux kernel scheme
>> which fits what I spoke of in the block above.
>>
>>
>> As Emmanuel wrote, we have several tasks to do:
>> - documentation of the new features
>> - update the current documentation
>> - update the examples
>> - tooling
>> - bug fixing
>> - renew Open Group certification?
>> I'm in doubt we can do this within 3 weeks.
>>
>>
>> Well no matter how long that might take people can still build the
>> server if they like and we should have nightly builds available for
>> testing between these periods. I was a +1 on the switch from doing 1.5.x
>> builds to starting to bring forth a 2.0.
>>
>>
>> An M1 could indicate to our users: hey, ApacheDS now supports RFC 4533
>> replication and CiDIT. Help to test it. Test interoperability with
>> OpenLDAP. Provide feedback.
>>
>>
>> I think we should just release the 2.0.0 in 3 weeks and let people go
>> wild with it.
>>
>>
>> And for us it indicates: no more big-bang refactoring till 2.0 GA, but
>> we can still modify API during bug fixing.
>>
>>
>> The same fits for a 2.0.1 ... 2.0.*. I think we should keep things
>> simple here. Just because some projects use this M* scheme that does not
>> mean we should too.
>>
>>
>>
>> > The next thing we need to talk about is what the major, minor and mico
>> > releases signify to our users. Here's how I look at it in terms
>> of our
>> > user agreement:
>> >
>> > o major releases do not guarantee interoperability out of the box
>> > since internal and external interfaces, db formats, and the entire
>> > architecture may change
>> > o minor releases guarantee interoperability, interface integrity, db
>> > format consistency across releases with architectural stability. New
>> > features may be introduced and some features may be enhanced.
>> > o micro releases are simple bug fix releases which do not introduce
>> > anything new
>>
>> +1
>>
>> Kind Regards,
>> Stefan
>>
>>
>>
>>
>>
>> --
>> Alex Karasulu
>> My Blog :: http://www.jroller.com/akarasulu/
>> Apache Directory Server :: http://directory.apache.org
>> Apache MINA :: http://mina.apache.org
>> To set up a meeting with me: http://tungle.me/AlexKarasulu
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkv6PM8ACgkQ2lZVCB08qHEINACfalg/ibbued1W8wtGnE/ZKMJ5
KA4Amwcb+JGwV8d+gSJJcTm4iwTngkmh
=C1EQ
-----END PGP SIGNATURE-----
Re: [ApacheDS] Release versioning scheme.
Posted by Stefan Seelmann <se...@apache.org>.
Hi Alex,
I don't insist on those milestone releases. I just find them useful in
this case to be able to release fast, even if not everything is
finished, and to avoid that users think everything is polished.
Anyway, I totally agree with all your other points. So let's go on.
Kind Regards,
Stefan
Alex Karasulu wrote:
>
>
> On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <seelmann@apache.org
> <ma...@apache.org>> wrote:
>
> Alex Karasulu wrote:
> > Yes this scheme is much more appealing. However I'm not into this
> > milestone designation. I don't really see the point (perhaps someone
> > might show me in this thread). Let me explain my thinking below.
> >
> > To me you either have a release or you don't release. With the httpd
> > scheme above you have no need for milestone releases because 2.0.0,
> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
>
> No sure about that, httpd released a 2.3.5-alpha
>
>
> Hmmm OK I didn't know that. Regardless though I think the designation is
> unnecessary. The new minor release number inherently represents
> something that has changed by adding new features which may destabilize
> the software. We don't really know how much and if that amount means
> give it an alpha flag. How alpha is alpha?
>
> Plus with certain tooling this -alpha designator might be an issue. Why
> bother dealing with the risk?
>
>
> > features. Hence the minor bump. The micro releases are just bug fix
> > releases that do not introduce new features after the minor
> > ("milestone") release. So this is why this httpd scheme does not need
> > M1, M2 .. a la eclipse style releases.
>
> I think milestones can be used to indicate that we are on the way to
> 2.0, but it's not ready yet.
>
>
> I'm still not convinced of this technique. I know eclipse uses this but
> it's not very appealing to me. I prefer the new Linux kernel scheme
> which fits what I spoke of in the block above.
>
>
> As Emmanuel wrote, we have several tasks to do:
> - documentation of the new features
> - update the current documentation
> - update the examples
> - tooling
> - bug fixing
> - renew Open Group certification?
> I'm in doubt we can do this within 3 weeks.
>
>
> Well no matter how long that might take people can still build the
> server if they like and we should have nightly builds available for
> testing between these periods. I was a +1 on the switch from doing 1.5.x
> builds to starting to bring forth a 2.0.
>
>
> An M1 could indicate to our users: hey, ApacheDS now supports RFC 4533
> replication and CiDIT. Help to test it. Test interoperability with
> OpenLDAP. Provide feedback.
>
>
> I think we should just release the 2.0.0 in 3 weeks and let people go
> wild with it.
>
>
> And for us it indicates: no more big-bang refactoring till 2.0 GA, but
> we can still modify API during bug fixing.
>
>
> The same fits for a 2.0.1 ... 2.0.*. I think we should keep things
> simple here. Just because some projects use this M* scheme that does not
> mean we should too.
>
>
>
> > The next thing we need to talk about is what the major, minor and mico
> > releases signify to our users. Here's how I look at it in terms
> of our
> > user agreement:
> >
> > o major releases do not guarantee interoperability out of the box
> > since internal and external interfaces, db formats, and the entire
> > architecture may change
> > o minor releases guarantee interoperability, interface integrity, db
> > format consistency across releases with architectural stability. New
> > features may be introduced and some features may be enhanced.
> > o micro releases are simple bug fix releases which do not introduce
> > anything new
>
> +1
>
> Kind Regards,
> Stefan
>
>
>
>
>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
> To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [ApacheDS] Release versioning scheme.
Posted by Alex Karasulu <ak...@apache.org>.
On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <se...@apache.org>wrote:
> Alex Karasulu wrote:
> > Yes this scheme is much more appealing. However I'm not into this
> > milestone designation. I don't really see the point (perhaps someone
> > might show me in this thread). Let me explain my thinking below.
> >
> > To me you either have a release or you don't release. With the httpd
> > scheme above you have no need for milestone releases because 2.0.0,
> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
>
> No sure about that, httpd released a 2.3.5-alpha
>
>
Hmmm OK I didn't know that. Regardless though I think the designation is
unnecessary. The new minor release number inherently represents something
that has changed by adding new features which may destabilize the software.
We don't really know how much and if that amount means give it an alpha
flag. How alpha is alpha?
Plus with certain tooling this -alpha designator might be an issue. Why
bother dealing with the risk?
> > features. Hence the minor bump. The micro releases are just bug fix
> > releases that do not introduce new features after the minor
> > ("milestone") release. So this is why this httpd scheme does not need
> > M1, M2 .. a la eclipse style releases.
>
> I think milestones can be used to indicate that we are on the way to
> 2.0, but it's not ready yet.
>
>
I'm still not convinced of this technique. I know eclipse uses this but it's
not very appealing to me. I prefer the new Linux kernel scheme which fits
what I spoke of in the block above.
> As Emmanuel wrote, we have several tasks to do:
> - documentation of the new features
> - update the current documentation
> - update the examples
> - tooling
> - bug fixing
> - renew Open Group certification?
> I'm in doubt we can do this within 3 weeks.
>
>
Well no matter how long that might take people can still build the server if
they like and we should have nightly builds available for testing between
these periods. I was a +1 on the switch from doing 1.5.x builds to starting
to bring forth a 2.0.
> An M1 could indicate to our users: hey, ApacheDS now supports RFC 4533
> replication and CiDIT. Help to test it. Test interoperability with
> OpenLDAP. Provide feedback.
>
>
I think we should just release the 2.0.0 in 3 weeks and let people go wild
with it.
> And for us it indicates: no more big-bang refactoring till 2.0 GA, but
> we can still modify API during bug fixing.
>
>
The same fits for a 2.0.1 ... 2.0.*. I think we should keep things simple
here. Just because some projects use this M* scheme that does not mean we
should too.
>
> > The next thing we need to talk about is what the major, minor and mico
> > releases signify to our users. Here's how I look at it in terms of our
> > user agreement:
> >
> > o major releases do not guarantee interoperability out of the box
> > since internal and external interfaces, db formats, and the entire
> > architecture may change
> > o minor releases guarantee interoperability, interface integrity, db
> > format consistency across releases with architectural stability. New
> > features may be introduced and some features may be enhanced.
> > o micro releases are simple bug fix releases which do not introduce
> > anything new
>
> +1
>
> Kind Regards,
> Stefan
>
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [ApacheDS] Release versioning scheme.
Posted by Stefan Seelmann <se...@apache.org>.
Alex Karasulu wrote:
> Yes this scheme is much more appealing. However I'm not into this
> milestone designation. I don't really see the point (perhaps someone
> might show me in this thread). Let me explain my thinking below.
>
> To me you either have a release or you don't release. With the httpd
> scheme above you have no need for milestone releases because 2.0.0,
> 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
No sure about that, httpd released a 2.3.5-alpha
> features. Hence the minor bump. The micro releases are just bug fix
> releases that do not introduce new features after the minor
> ("milestone") release. So this is why this httpd scheme does not need
> M1, M2 .. a la eclipse style releases.
I think milestones can be used to indicate that we are on the way to
2.0, but it's not ready yet.
As Emmanuel wrote, we have several tasks to do:
- documentation of the new features
- update the current documentation
- update the examples
- tooling
- bug fixing
- renew Open Group certification?
I'm in doubt we can do this within 3 weeks.
An M1 could indicate to our users: hey, ApacheDS now supports RFC 4533
replication and CiDIT. Help to test it. Test interoperability with
OpenLDAP. Provide feedback.
And for us it indicates: no more big-bang refactoring till 2.0 GA, but
we can still modify API during bug fixing.
> The next thing we need to talk about is what the major, minor and mico
> releases signify to our users. Here's how I look at it in terms of our
> user agreement:
>
> o major releases do not guarantee interoperability out of the box
> since internal and external interfaces, db formats, and the entire
> architecture may change
> o minor releases guarantee interoperability, interface integrity, db
> format consistency across releases with architectural stability. New
> features may be introduced and some features may be enhanced.
> o micro releases are simple bug fix releases which do not introduce
> anything new
+1
Kind Regards,
Stefan