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
