Over the weekend I will summarise the previous emails concerning the scope of the next release and re-list the features that the threads seem to see going into it. [Unless someone else beats me to it]
What I do to get my list is to build the potential new jar, then I run a javadiff bash script between the two jars. It's a bit rough, but generally works okay. This shows me API differences. Any hidden bugfixes are automatically assumed to go with the next release. These are obtainable via the cvs log command, and in the previous release I collated the cvs logs into one file of changes, and matched them against Bugzilla just to be sure. >From memory of the various threads started by this, the only sub-package that might be added is the math subpackage, and this is because NumberRange has been relocated to here and expanded upon. This doesn't need to happen however. Maybe util too. >From a marketing point of view, a 1.1 makes a lot of sense. People seem to expect x.0 to have all the new features, when in fact x.0 means that a product has changed features. From a technical point of view, 2.0 seems more likely as 1.0 code will not all work with the 1.1 jar. Once scope is decided upon, and unit-tests and javadocs are then happy, an rc1 build is created. The more eyes that can see this the better. A vote is called as to whether a release of lang can go, though I'd expect all interested parties to have taken part pretty much in the scope agreements. Once an rc that is considered correct is created, it is released. None of this is written in stone [except the vote], it just seems to be how the previous releases have evolved and I imagine we will continue to follow that system. Feel free to tune into the Developers mail list and filter on [lang]. If we go quiet on the subject, give us a good kick. Hen On Fri, 24 Jan 2003, Gary Gregory wrote: > I do not think we are quite done with this topic. Can someone clarify where > we stand? > > Thank you, > Gary > > -----Original Message----- > From: Gary Gregory [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 22, 2003 7:42 AM > To: 'Jakarta Commons Users List' > Subject: RE: [lang] Is there a schedule? > > > Are we saying that a 1.0.2 release is not possible since the fixes are > significant and break API contracts which is why the next release /must/ be > a minor or major release /and/ that if we are talking about a major or minor > release then we must talk about (argue) new features, which is "painful"? > > What about a minor (1.1) release with all bug fixes and no new feature? Then > a release for new features. Just one step at a time, splitting the arguing > b/w bug arguments and feature arguments? > > Gary > > -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 21, 2003 3:11 PM > To: Jakarta Commons Users List > Subject: Re: [lang] Is there a schedule? > > > From: "Henri Yandell" <[EMAIL PROTECTED]> > > On Tue, 21 Jan 2003, Gary Gregory wrote: > > > > > WRT Commons-Lang, I would like to get the ToStringBuilder reflection > fixes > > > for class hierarchies from a released build rather than a nightly build. > > > > > > A maintenance release would allow me to further clean up our code base > away > > > from our various inconsitent toString implementations and use the now > fixed > > > ToStringBuilder. I would be happy with a 1.0.x level release but I am > not > > > sure if this is easy to do for you guys. A 1.0.x release could simply > not > > > include new packages. > > > > +1 to a release of Commons Lang 1.0.2, with bugfixes but no new > > functionality. > > -1. The changes being talked about here are definitely 1.1 if not 2.0. they > are not minor bug fixes, but major ones. > > Stephen > > > I suspect that many of the new functionalities in the dev tree will be > > argued long and hard over. > > > > We also need to get the 2.0 arguments started again, but it's all getting > > quite tiring and painful. > > > > > What happens if a nightly build fails in a unit test? Is it not posted? > > > > I think so, but am not 100%. > > > > Hen > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
