commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] Lang 2.0 release?
Date Thu, 21 Aug 2003 05:09:42 GMT
I think you've convinced me (almost) to just release a 2.0. But... it would
be nice to have other projects that depend on [lang] to migrate first but...
(going in circles) I guess as an outside project, I would only want to
bother doing a migration once, not once for a beta/rc and another time for
the real release. So I am back to where I started from I think: release.

Gary (dizzy)

> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Wednesday, August 20, 2003 21:55
> To: Jakarta Commons Developers List
> Subject: RE: [lang] Lang 2.0 release?
> 
> 
> 
> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message