> I guess I wasn't quite clear there. It was my intention as well to strip > the "collections" part of the current packaging before the release. And I guess I wasn't clear in that I saw leaving it in a collections package for its first release as being useful. Let me explain...
IMHO these highly useful classes have been relatively hidden within [collections] and haven't gained a clear community (virtually no emails about them). They are being used quietly though, always good. Now that a new project has been created, I think that we are seeing signs of more interest and more committers. I want to retain some flexibility for new committers (and I guess I include myself in that) to make changes and improve the codebase. The reason that this matters is that there are interfaces involved that we can't change later. So what might get changed? Well I don't see the need to remove anything from the current interfaces. I do believe that there are some methods that can be added. (separate email thread). I have also said that I believe the package structure needs examining, as I definitely want to add some maps. This is why I would like the first [primitives] release to be in the collections package (and was why I originally proposed a 0.1 number). a) Release 1.0 [primitives] using *collections.primitives** package. b) Agree and write new interfaces and code in new packages based on the existing code, and using the same tests. c) Deprecate [primitives] *collections.primitives** classes to the new interfaces/code/packages. d) Release 2.0 of [primitives]. If I have understood things correctly, this serves the existing users and axion, as they get a released codebase with no package change at present. If desired, they can use this for all time. It also serves future [primitives] users in that it can improve on what we already have. I hope that I have explained clearly this time as to where I want [primitives] to go, and how I want to get there. Let me know if this works for you as a plan. Stephen From: "Rodney Waldhoff" <[EMAIL PROTECTED]> > I guess I wasn't quite clear there. It was my intention as well to strip > the "collections" part of the current packaging before the release. > > The plan then is to: > > A) Repackage what's currently in [primitives] from > org.apache.commons.collections.primitives.** to > org.apache.commons.primitives.** > > B) Deprecate what's currently in [collections] at *.primitives.**, to > point to the [primitives] version > > C) Ask the maven folks to publish a -SNAPSHOT and dated build from the > resulting commons-collections HEAD to the ibiblio repository > > D) Initiate a 1.0 release of [primitives] with the current code base, > slighly repackaged. > > E) Remove the *.primitives.** packages from [collections], either before > or after D. (With all things being equal, we should probably at least > allow the deprecation warnings to show up in the nightly builds for a > couple of days first.) > > Is that right? > > (Assuming it is) I'll volunteer to be the primitives 1.0 release manager, > but I won't have much time until next week to dig into it. Also, I > haven't done a release since the mirroring structure was set up, but I > suppose I'll be able to muddle through. Are there documenation on that > process somewhere? > > - Rod <http://radio.weblogs.com/0122027/> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
