I've got some stuff I'm interested in having bake some more,
I'm playing fast and loose with core loading (SOLR-1293 and associated).
Particularly what's up with the interaction, if any, between this and
SolrCloud (I expect that this is just not supported in SolrCloud, but...)
It's going to get a bit awkward to manage soon (yeah, I know that's my
problem). So far I haven't checked any of this in.
So, should I
1> just accumulate them all into one really big patch? I really don't
want to do this, some if this is iffy enough that I think it'd be clearer
to track down if there were incremental patches applied. I know, write
it right the first time.....
2> maintain my separate patches and commit after 4.1 is labeled?
3> ???
Note that the changes I'm working on should NOT change current
behavior, but there's always the chance of spillover. This applies to
either the 4.0.1 or 4.1 I guess.
On Thu, Oct 25, 2012 at 10:08 PM, Robert Muir <[email protected]> wrote:
> On Thu, Oct 25, 2012 at 9:47 PM, Mark Miller <[email protected]> wrote:
>> In my case, all the important bug fixes were only just recently fixed or I'm
>> still fixing them - so for my stuff, I see a larger negative with 4.1 vs
>> 4.0.1. They won't bake long in either version - but they should go out soon
>> regardless.
>>
>
> This can be easily mitigated: just commit to trunk and spin up an
> extra jenkins against it. But 4.1 is already stable on the lucene side
> and I don't think we should go backwards.
>
> There is just a lot of little shit, like javadocs fixes, improvements
> to the build, etc that would make it a higher quality release. We also
> have enough features already to make it a real release
> (http://wiki.apache.org/lucene-java/ReleaseNote41).
>
> I'm not really worried about playing tricks trying to convince users
> to upgrade, I think we should just focus on quality releases and that
> comes naturally.
>
> ---------------------------------------------------------------------
> 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]
