directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] Release versioning scheme.
Date Tue, 25 May 2010 05:05:46 GMT
On Mon, May 24, 2010 at 12:17 PM, Emmanuel Lecharny <>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<
>>> <>>  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

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 ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message