Re: [DISCUSS] define what/when a 4.0-beta should be
On Wed, Jul 25, 2012 at 9:28 AM, Jan Høydahl jan@cominvent.com wrote: Kudos Robert for pushing on and try to establish some target deadlines for the beta and GA. Given that july is holiday season (Norway is practically closed) and also August in much of Europe, I'd say mid-august for a Beta and end of september for GA. If someone feels the need or more releases (e.g. Alpha2) in between that's ok. Jan, thanks for your feedback. As far as additional alpha or beta: I'm not sure thats realistically possible. Lets consider the time and effort it takes to spin a typical release: 1 day to generate, upload, and smoke test artifacts for the release candidate (including fixing stuff that always seems to be discovered) 3 days for the voting period (usually times two, there is typically one respin) 1 day actually releasing: updating the website, uploading the massive javadocs, sending emails. So I think this process is usually about a week. Additionally I think there is little point to issuing alpha/beta releases if we don't give users the time to actually install them and report back problems. That being said if someone wants to do all this work, I certainly wouldn't vote against it! I'm just trying to make sure we all think about this realistically. Personally I'd like to spin up an RC say, next friday (August 3rd). Given a typical timeframe that leads to us putting out the beta around Monday August 13th: mid-August as you suggested. And this gives everyone a week (from today) to fix more stuff before the beta. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [DISCUSS] define what/when a 4.0-beta should be
Kudos Robert for pushing on and try to establish some target deadlines for the
beta and GA.
Given that july is holiday season (Norway is practically closed) and also
August in much of Europe, I'd say mid-august for a Beta and end of september
for GA. If someone feels the need or more releases (e.g. Alpha2) in between
that's ok.
Here's a list of current blockers in Jira. Are there other that should be
marked blockers?
SOLR-3648 The /browse Solritas GUI does not work under SolrCloud - 500
error
SOLR-3292 /browse example fails to load on 3x: no field name specified
in query and no default specified via 'df' param
SOLR-3432 deleteByQuery silently ignored if updateLog is enabled, but
{{_version_}} field does not exist in schema
SOLR-3591 Startup error not reflected in Solr web view
SOLR-3471 Tests not working on Windows
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 24. juli 2012, at 20:03, Robert Muir wrote:
On Tue, Jul 24, 2012 at 1:25 PM, Mark Miller markrmil...@gmail.com wrote:
I thought you might be pressing for a final release sooner rather than
later, so mid August is my plea for the soonest date. I can take advantage
of more time for sure. At the same time, I'm hoping we release by the end of
the summer - but I thought you were in a larger hurry than me. I'd be even
more ready at the end of august then the middle of it.
I'm not in a hurry: except i dont want us to just sit around and drag
it on until next year, for the final to then look nothing like the
alpha :)
I don't mind either of your two options.
I'd be fine with dropping a beta that hits start of august or sooner, or
just working towards 4 at the end of august. I don't have any strong
feelings about that - I just vote we do final release mid august *earliest*.
ok cool, i think i would plan on maybe trying to get an RC for the
beta out next week or so. I don't want to commit to lucene api back
compat yet, I would like to just leave the guarantees the same for
now: if you think solr HTTP back compat is ok thing to do, i'll go
with your judgement there, I dont understand the details of all the
tradeoffs involved.
but if we commit to lucene api back compat, then thats no different
than a final release and will take longer I think to get everyone
happy with it going out (its a lot to commit to).
--
lucidimagination.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [DISCUSS] define what/when a 4.0-beta should be
On Mon, Jul 23, 2012 at 2:07 PM, Mark Miller markrmil...@gmail.com wrote: Lets get it out very soon and then perhaps it can be a short cycle and we can perhaps even 4 in mid to late August? If I called a VOTE today on a beta I'm thinking the earliest we could get it out would be Aug 1, and we want some time (at least a few weeks) for people to try it out before then spinning out a final. On the other hand I don't want to delay this thing too much because 4.0 has just taken forever. And the alpha release seems to maybe have provided us with the feedback we need... do we need another iteration? So I see two choices: 1. skip beta and we just work towards a final release. 2. spin beta RC like, now, today, and plan on a final release in september/october at the earliest (I imagine once we start talking about final people are going to really want to get a few things cleaned up first) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [DISCUSS] define what/when a 4.0-beta should be
I vote for proceeding with the existing plan: alpha, beta at least one month later, final at least one month later: roughly your #2, Robert. Sticking to the plan seems worth the (potential) extra month wait to me. - Steve -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Tuesday, July 24, 2012 12:22 PM To: dev@lucene.apache.org Subject: Re: [DISCUSS] define what/when a 4.0-beta should be On Mon, Jul 23, 2012 at 2:07 PM, Mark Miller markrmil...@gmail.com wrote: Lets get it out very soon and then perhaps it can be a short cycle and we can perhaps even 4 in mid to late August? If I called a VOTE today on a beta I'm thinking the earliest we could get it out would be Aug 1, and we want some time (at least a few weeks) for people to try it out before then spinning out a final. On the other hand I don't want to delay this thing too much because 4.0 has just taken forever. And the alpha release seems to maybe have provided us with the feedback we need... do we need another iteration? So I see two choices: 1. skip beta and we just work towards a final release. 2. spin beta RC like, now, today, and plan on a final release in september/october at the earliest (I imagine once we start talking about final people are going to really want to get a few things cleaned up first) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [DISCUSS] define what/when a 4.0-beta should be
I thought you might be pressing for a final release sooner rather than later, so mid August is my plea for the soonest date. I can take advantage of more time for sure. At the same time, I'm hoping we release by the end of the summer - but I thought you were in a larger hurry than me. I'd be even more ready at the end of august then the middle of it. I don't mind either of your two options. I'd be fine with dropping a beta that hits start of august or sooner, or just working towards 4 at the end of august. I don't have any strong feelings about that - I just vote we do final release mid august *earliest*. - Mark On Jul 24, 2012, at 12:22 PM, Robert Muir wrote: On Mon, Jul 23, 2012 at 2:07 PM, Mark Miller markrmil...@gmail.com wrote: Lets get it out very soon and then perhaps it can be a short cycle and we can perhaps even 4 in mid to late August? If I called a VOTE today on a beta I'm thinking the earliest we could get it out would be Aug 1, and we want some time (at least a few weeks) for people to try it out before then spinning out a final. On the other hand I don't want to delay this thing too much because 4.0 has just taken forever. And the alpha release seems to maybe have provided us with the feedback we need... do we need another iteration? So I see two choices: 1. skip beta and we just work towards a final release. 2. spin beta RC like, now, today, and plan on a final release in september/october at the earliest (I imagine once we start talking about final people are going to really want to get a few things cleaned up first) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [DISCUSS] define what/when a 4.0-beta should be
On Tue, Jul 24, 2012 at 1:25 PM, Mark Miller markrmil...@gmail.com wrote: I thought you might be pressing for a final release sooner rather than later, so mid August is my plea for the soonest date. I can take advantage of more time for sure. At the same time, I'm hoping we release by the end of the summer - but I thought you were in a larger hurry than me. I'd be even more ready at the end of august then the middle of it. I'm not in a hurry: except i dont want us to just sit around and drag it on until next year, for the final to then look nothing like the alpha :) I don't mind either of your two options. I'd be fine with dropping a beta that hits start of august or sooner, or just working towards 4 at the end of august. I don't have any strong feelings about that - I just vote we do final release mid august *earliest*. ok cool, i think i would plan on maybe trying to get an RC for the beta out next week or so. I don't want to commit to lucene api back compat yet, I would like to just leave the guarantees the same for now: if you think solr HTTP back compat is ok thing to do, i'll go with your judgement there, I dont understand the details of all the tradeoffs involved. but if we commit to lucene api back compat, then thats no different than a final release and will take longer I think to get everyone happy with it going out (its a lot to commit to). -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [DISCUSS] define what/when a 4.0-beta should be
My opinions inline: On Jul 23, 2012, at 12:28 PM, Robert Muir wrote: Hello, We released the 4.0-alpha at the beginning of the month, I think its time we start figuring out what/when the beta should be. What: Originally one proposal was that the 4.0-beta would offer some additional guarantees (such as keeping API backwards compatibility / config-file backwards compatibility). We should think about exactly what this means: 1. does it make sense to guarantee API backwards compatibility for Solr? I think for the HTTP API's yes - we should try and provide the same level of support as a full release. For the java API's, since we have always been more flexible there with Solr even with full releases, I think we should remain so. 2. what about the fact so many Lucene apis are @experimental anyway? Yeah, you'd hope we would be able to start dropping some of those experimental warnings. We should review some that have had that for a long time. 3. what about the fact that if we offer API+config file backwards, then that means all we can do in 4.0-final is fix bugs (we could just as easily do that in a 4.0.1). That's a point - I've got some important hanging chads I'm trying to plow through myself though. I could really use the extra couple weeks regardless - I want to make sure 4 is really smooth for the stuff I have. That's just me and where I am though. You could still make an argument to go GA now and follow up in 4.1 - I just want to make sure 4 makes a great first impression - and those couple extra weeks will mean a lot to me in doing that. You could say that always, but I've just kind of planned on having that time given the proposed schedule FWIW. Approx mid August for 4 final would be golden for me :) I've got a lot of doc to write :) 4. on the other hand if we make the caveats too crazy complicated, nobody will really understand it. When: Currently it seems like there is a fair amount of good feedback and bugs getting fixed. I don't want to get in the way of that. But I think a lot of this depends on What. If we commit to a real API/config-file backwards compatibility just like a normal release then I think its a really big commitment and just going to take longer. One idea is to offer less guarantees to get a beta out faster. I like that idea - I think we should phrase much like the alpha, but more :) Here are the promises, we are going to try even hard not to break anything in a wider area though - no guarantees if the problem is bad enough, but stronger guarantees than you had with Alpha. Normal release promises may have to be broken (just like sometimes on real releases actually) - but only after careful consideration about the benefits vs user interruption - not willy nilly. Lets get it out very soon and then perhaps it can be a short cycle and we can perhaps even 4 in mid to late August? Thanks -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
