commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [lang] Lang 2.0 release?
Date Thu, 21 Aug 2003 04:55:13 GMT


On Thu, 21 Aug 2003, Gary Gregory wrote:

> Inline...
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sent: Wednesday, August 20, 2003 20:44
> > To: Jakarta Commons Developers List
> > Subject: RE: [lang] Lang 2.0 release?
> >
> >
> >
> > On Wed, 20 Aug 2003, Gary Gregory wrote:
> >
> > > This is all good news. I have two Q's:
> > >
> > > (1) What about an RC-4 that is publicized to the commons-user list such
> > that
> > > real users can raise issues such that we can:
> > >
> > > 	(a) document them in a migration doc or
> > > 	(b) fix them.
> >
> > Dunno. Do we want users to be using RCs? I think I'd prefer to have them
> > use the x.0 and release an x.0.1 for any issues etc.
>
> Well, the changes that we have been going through, moving classes, removing
> code, etc, have been pretty radical from beta to beta and from RC to RC. I
> guess it is matter of expectations from the user base. I does sound, that
> now, right now, we have a stable build. I think it is a bit odd to release a
> 2.0 release with the explicit understanding that the user base should wait
> until a 2.0.1 to become the real stable release. Furthermore, what if, in
> theory, the changes asked by users to 2.0 would really not be backwards
> compatible with 2.0, therefore needing to call the next release a 2.1? Kind
> of odd to have a super short lived 2.0. All of my ramblings to say that it
> does not quite feel right to me to push a release out without a
> beta/rc/feedback cycle from *some* users.

It's a good point. The HttpClient guys have been in alpha/rc stage for
ages now for 2.0, meaning that anyone who is using HttpClient is probably
testing the rc and not using their v1.0. I imagine that HttpClient won't
be fixing bugs in the alpha/rc releases but just telling people to upgrade
to 2.0 when it is released.

In the end I think that it equates to the same thing. If we release a 2.0,
and there are reported bugs, we will release a 2.0.1. No question about it
[unless no one is working on the project by that time]. We'll be working
on a CVS branch and maintaining etc. I'm in favour of the latter as I
think the user will be better supported by a full early release than
by a beta phase. Just an opinion though/

If we release an rc4 [okay, it should be called something else to signify
a difference between internal rc and external rc] to users, even if we
move on to 2.1 or 3.0 we will still have to support the users on the rc.
Furthermore, should releasing an rc to users be voted upon and go via the
PMC? Even if we're not giving it a version number, it's a release we're
making to the userbase.

With a product like Lang, [or Collections, or Codec etc], I would expect
that the unit test coverage would be very high [we're getting there] and
that the quality of the unit tests is a greater foundation for stability
than the user base. With something like Jelly, HttpClient, Latka, I would
expect that the user base is going to try things the developers have never
considered and the unit tests really just show that an example situation
works correctly.

A lot of this is under the assumption that users only find bugs, they
don't make feature request changes to our version. As the rc1 showed, that
isn't true. We quickly had a user ask why lang.time wasn't being
released and deciding to release. With hindsight we could have gone to 2.0
and then 2.1 now.

I'm a believer in the release-early release-often mantra, with the only
proviso being that the quality improve each time, so this shades the way
in which I view a lot of this.

Hen


Mime
View raw message