On Tue, 14 Oct 2003, __matthewHawthorne wrote: > You may feel that the primitives code was "passed over for release for > no particularly good reason", but the community disagreed. There were a > lot of reasons discussed, and many developers chimed in with their > opinions. The consensus seemed to be that the primitive code should be > moved to another project. I think we should accept it and move on.
Just as I wrote, my comments were in reference to the 2.0 release of commons-collections. I stand by them. It may be interesting for you to go back into the archives and look at that debate. If I remember correctly, the lack of a list of doubles was considered a show-stopper at that time. Curiously, the "community" (of one, possibly two) that blocked the release at that time contributed significantly more opinions that code, documentation or support, and has since disappeared from jakarata commons entirely. > The fact that unreleased code is being used in production somewhere > shouldn't necessarily categorize it as releasable. It seems that code > has to stand on its own merit along with other commons code and releases > to be considered as such. My wording may be a little confusing; my > point is, just because you're using the code in production doesn't mean > that commons should release it. It seems to be more community oriented. The fact that the code in question is old, stable, 100% tested and features a design and implementation long informed by real world use suggests that this code is quite releasable. > There are some packaging issues that have yet to be solved, releasing > the current [primitives] code as v1.0 may cause some deprecation and > backwards compatibility headaches if changes occur (and it seems that > they will.) I think the best decision is to release the current code as > 0.1, and think about possible improvements and additions for 1.0. Let's consider the history of this code base: The code in question was initially developed for and by another project, which in turn contributed the code to commons-collections (following an informal and unanimously positive vote). This code was stable and release-ready at the time of the commons-collections 2.0 release. For reasons substantially weaker than the ones we're debating now, it was decided to hold back that code for the 2.0 release, forcing the donating project and user community to rely upon snapshot builds in the interim. Fast forward nearly a year. We're finally gearing up for a 3.0 release of commons-collections, and it is agreed (after much debate) to move this code to a distinct commons component. It is not suggested that changes to the existing code are warranted, nor that the code isn't release ready, but the move is made simply in the interest of maintaining a more focused scope. This entails more delays and less backwards-compatibility. Now it is suggested that it is not reasonable to release this old, stable, 100% unit tested, well field tested, informed-by-real-world-use code without adding a host of new types that don't yet exist and are of hypothetical utility. This will result in additional delays and even less backwards-compatibility. > I think the best decision is to release the current code as > 0.1, and think about possible improvements and additions for 1.0. I agree, except what you're calling 0.1 should be 1.0. Calling the *release* 0.1 with the thought that that somehow absolves us from following a backwards-compatible deprecation policy is simply flawed. Adding a host of new types whose design is uniformed by real-world use, whose implementation is significantly newer than the existing code, and that has never been used outside of internal unit tests and thinking that is somehow more stable or more reasonably considered a 1.0 release is similarly flawed. This is an insufficient reason to further delay a 1.0 release of this code base. Projects that regularly disregard the interests of their contributors and regularly and repeatedly inconvenience their early-adopters risk losing them. Jakarta Commons in general, and this code base in particular, has already suffered at the hands of folks who've neither contributed to nor used the code in question, but are more than happy to chime in with superficial design decisions. The existing code is release ready, and as such should be released. Let's haggle about a fresh color for the bike shed for the 2.0 release. - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
