commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] 1.0 release foci (fwd)
Date Fri, 23 Aug 2002 22:56:29 GMT

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.


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:   <>
For additional commands, e-mail: <>

View raw message