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
