commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Downey" <steve.dow...@netfolio.com>
Subject RE: [lang] 1.0 release foci (fwd)
Date Sat, 24 Aug 2002 01:45:34 GMT
I was thinking that a release is imminent. Judging from Stephen's original
list, which seems like a good one, there's essentially just clean up work.
But there's also interest in ongoing development. A branch allows that.

Branching when the classes you are going to release are ready is a lot
harder. It means more clean up work after the branch. And more temptation to
add just one more feature to the classes scheduled for release. Which are
the ones that, inevitably, are buggy.



> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Friday, August 23, 2002 6:56 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] 1.0 release foci (fwd)
>
>
>
> You're suggesting we branch now, do parallel development until a release
> on releasable items, then handle the branch as a maintainance branch after
> a release??
>
> I was thinking that we would branch when those classes intended for
> release were ready, except that branch would not contain the classes that
> are not intended to do [they'd be removed directly after branching].
>
> It'll depend on how many classes are both included in the release, and
> have post 1.0 work going on on them.
>
> Now I understand your suggestion, I'm not averse to it.
>
> Hen
>
>
> On Fri, 23 Aug 2002, Steve Downey wrote:
>
> > That's what the branch is for. There's obviously a lot of work
> that people
> > want to do in the project. They can continue to work on HEAD.
> Work on the
> > release goes on in the branch, named something like
> LANG_RELEASE_1_BRANCH.
> >
> > Any commits to the branch should be scrutinized closely. If
> they don't fix a
> > defect, they should probably be reverted. If they do fix a
> defect, the change
> > also needs to be applied to HEAD.
> >
> > To be really anal rententive, you can require that any defect
> fixed have a
> > corresponding entry in the bug tracking system. But I don't think that's
> > necesary here.
> >
> > A library project doesn't have the same lifecycle as a product
> like Tomcat or
> > Ant. For those, it's pretty clear when things are done, and
> everything slows
> > down, then it's time for a release time. A library has work
> ongoing more of
> > the time. There's almost always something to be improved,
> changed, or added.
> > Especially an open ended one like [lang] or [collections].
> >
> > "There come's a time in every project when it's necessary to shoot the
> > engineers and ship the product."
> >
> > Making a branch lets the release engineers take over from the
> developers.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message