+1 to getting 4.0 alpha out asap for user feedback. We have incredible (but largely unused) new features in 4.0.
I like the plan to cut branch for 4.0, and trunk becomes future 5.0, and 3.6.x becomes bugfix only, as an atomic event :) Then we should try to focus on prepping/iterating on the 4.0 branch for real release: going through Jira and marking (and fixing!) blocker issues, testing, scrutinizing the new APIs, etc. Mike McCandless http://blog.mikemccandless.com On Wed, Jan 11, 2012 at 2:31 PM, Simon Willnauer <[email protected]> wrote: > On Sun, Jan 8, 2012 at 8:05 PM, Robert Muir <[email protected]> wrote: >> On Sun, Jan 8, 2012 at 1:36 PM, Simon Willnauer >> <[email protected]> wrote: >>>> >>>> From the tests/bugfixing perspective, on trunk its not hard to dig >>>> into stuff here and there and find lots of really horrible bugs that >>>> exist in trunk-only. This is a sign that our tests are not good enough >>>> and that the code is not stable enough. >>> >>> I don't understand this entirely, can you elaborate? if there are >>> horrible bugs there should be issues marked as blocker. >>> >> >> Well maybe I delivered this idea the wrong way: i didn't mean i >> secretly know of any bugs or anything like that: >> I just mean as a trend, recently over the last few months I have >> noticed lots of bugs that only affect 4.x but don't affect 3.x > > ah ok phew :) >> >> I think this is natural, a lot has changed, but to mitigate that we >> need to beef up tests and spend more time reviewing and trying to >> clean up. >> I'm just as guilty as anyone else when it comes to these changes >> without having adequate tests. >> >>> >>> I did ask to push the release tomorrow. I personally feel some >>> frustration that lucene 4 is still not released and I think we are >>> really close. >> >> I'm pretty frustrated working on some code for years that is unreleased. >> >>> From my perspective we should build some kind of roadmap >>> to get lucene 4 or a beta out lets say within the next 2 month and >>> concentrate on getting the remaining issues resolved. We should >>> collect issues and problems and mark them as blockers so we can pick >>> them up and get it out of the door. Right now all the issues you >>> listed are somewhat known but there is no way to access them, I >>> suggest we open JIRA ticket and decide issue per issue if they are >>> blockers or not. >> >> I do think we need some kind of 'vague plan' as much as we can have >> one in open source. Here is what I propose: >> >> 1. we decide that 3.6 (no reason to call it 3.9?) should be the last >> minor release on 3.6, lets try to make a nice 3.6,... we can then >> issue bugfixes like 3.6.1, 3.6.2, ... > > +1 to this. lets get 4.0 rolling... I don't think we need to jump to 3.9 > >> 2. copy trunk to branch_4x and call it our 'stable branch' (even >> though it isn't, not yet). > > +1 I think we should actually do that soonish, is there anything which > keeps us from branching IMO today is as good as tomorrow. What is the > status of solr-cloud? I mean is this going to be ready within a > reasonable amount of time? That feature by itself could justify a 4.1 > release immediately I'd say. > >> 3. trunk is now 5.x and open for scary changes like trunk is today. > > +! >> 4. eventually, when its right, we issue alpha or beta or real release >> off branch_4x for 4.0 > > agreed, I think we should never again release even a alpha off trunk. > On trunk folks should be allowed to go crazy and do scary changes... > on the stable / stabelizing branches we should be more conservative. > > >> >> I think this has some good practical implications: >> 1. people can still add new scary cool fun stuff to trunk as always. >> 2. new scary stuff isnt being added to branch_4x constantly >> destabilizing it (but certainly features that are safe, just like >> branch_3x today!) >> 3. since initially branch_4x and trunk are close, we essentially >> double our jenkins coverage (currently we spend half of it on 3.x, but >> this isn't helping stabilize 4.x code) >> >>> A SimpleText impl for docvalues are certainly nice to >>> have but not a blocker from my perspective. I already worked on it and >>> it will make it into 4.0 but we need to mark those issues that are >>> real blockers. >>> >> >> I actually think we should have a SimpleText impl for everything, here's why: >> 1. we need multiple implementations to flush out any assumptions in >> the abstract APIs. >> 2. we need to ensure multiple impls actually work for backwards >> compatibility to actually work in the future. >> 3. we need to fix tests to not have things like hard-coded assumptions >> about filenames so the tests are actually useful. >> >> Sorry for the example by the way, i didnt mean to pick on docvalues. >> Probably even worse is the fact I left a lot of codec impls really >> bundled together inside 4.x impls without splitting out the 3.x stuff. >> Until we do this, how do we know back compat will really work with >> codecs? >> >> -- >> lucidimagination.com > > --------------------------------------------------------------------- > 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]
