> > > I would like deprecation to happen for a time period before deletion, if > > > the code was not part of a release, especially in Commons, where the code > > > is by design meant to be used by others. And the code base can be stable, > > > without a release for a long time. > > > </rant> > > > > Bless you dIon. > > > > More frequent releases and/or policies like you describe would help. > > > > But mostly, we need people to care and work together. > > > > I agree that "working together" is important. IMHO, that includes a few > more steps by the people that extract a reusable chunk of code from some > other project into a sandbox module -- if the originating project adopts a > dependency on a sandbox project, there's a fair degree of "shame on you" > for them as well as for people working on the sandbox library. > > And yes, I'm currently in the same boat on one of my big projects (Struts > HEAD depends on commons-resources from the sandbox). The difference is > that there is no way I'd ever do a final release of Struts 1.1 without > having commons-resources promoted to the Commons and released (or removing > the dependency). > > > - Sam Ruby > > > > Craig McClanahan >
(An outsider's point.) What about the IBM eclipse practice? They have - nightly builds (same way as gump) - intergration builds (this can be the mediator concept between realeases and simple builds and they have them cca. every week) - milestone releases (dev releases in jakarta parlance) - beta releases - and releases. incze -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
