Sean, Mega kudos for starting a good thread. These issues needed a good airing.
On Tue, Nov 2, 2010 at 4:53 AM, Sean Owen <[email protected]> wrote: > Not surprisingly some good thoughts and some convergence on sensible > compromises between competing concerns. I think the code and community are > on a good trajectory as a result. Let's look towards a 1.0 release next. We > will have in mind that what is present now will soon be blessed as 1.0 and > align judgments accordingly. > On 2 Nov 2010 11:38, "Grant Ingersoll" <[email protected]> wrote: > > > > On Nov 1, 2010, at 11:05 PM, Jeff Eastman wrote: > > > >> Sorry to join in late, but I've read all the posts and think there a lot > of good ideas in them. > >> - I like the idea that 1.0 means we have some stable, polished code that > does what it does really well. Really well. > >> - Backward compatibility of 1.x is important. Our user group is growing > and won't appreciate whipsawing > > > > Definitely. However, we shouldn't be so rigid as to not allow > well-documented breaks within a major version (i.e. 1.x). We should always > strive for back compat within a major release and even across major > versions > (1.x to 2.x), but I doubt we will ever be able to absolutely guarantee it. > Maintaining it for the sake of maintaining it often leads to a whole lot of > clutter in your APIs due to all the deprecations. Communication with the > community is the key, in my book, especially b/c are release cycles aren't > all that often (twice a year, it seems) > > > > I do think, however, that trunk + branch tends help mitigate this. > > > >> - OTOH, I'd hate to see 1.0 mean we no longer tolerate experimental code > that is working its way up to production standards > >> - I like Ted's idea of an incubator area where these more tentative > features can germinate and someday become production ready > > > > I like the Incubator in principal, but in practice it often is treated > separately not so much by developers, but by the lawyers who are approving > it. I've seen this more than once with Lucene's "contrib" modules. There's > a > notion that they are second class citizens, when in reality they just > aren't > needed by everyone in all situations so they aren't marked as core. > > > > I much prefer we simply put things where they would belong if they were > fully baked, but mark them with an annotation such as @mahout.experimental. > As long as they compile and their tests pass, I don't see the harm. The > only > way they get better is by people trying them and kicking the tires. This is > true no matter how mature the code is. > > > > At any rate, this is really good stuff for a community to flesh out, so I > am glad we are having the conversation. I'd propose we work to get 1.0 out > within the next 6 months or so and then move to the trunk + stable branch > model. Cutting edge stuff goes on trunk, polish goes on both trunk and > stable branch (via SVN merge from trunk back to the branch). As the trunk > stuff bakes, we may or may not want to backport it on a case by case basis. > This model works well for most communities at the ASF from what I've seen. > > > > -Grant >
