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.
In any case, regardless of the opinion about whether 4.1 really would be more stable than a 4.0.1 (I think it could be argued even in the time to bake case), I don't believe users will react with that line of reasoning on average. I think the best way to get users to upgrade and avoid some nasty bugs is to label something 4.0.1. Like I said, when you see a 4 go to 4.0.1, for most, it's a no brainer to upgrade. In fact, you normally assume you should - bugs must have been fixed - potentially bad ones. At worst it gets you to read the changes. Now when a 4.1 comes out, that's a feature release. That feels more dangerous (regardless of reality). That's something perhaps I'll think about in a few months when things slow down - or not at all. That's the type of thing we have changed runtime behavior in before - or made back compat break calls. Even with the new development style, that stuff will come up. And even if it didn't, it's just how people think about software and versions in general - and we are not easily going to change that - IMO it's best to use it. - Mark On Oct 25, 2012, at 9:02 PM, Robert Muir <[email protected]> wrote: > On Thu, Oct 25, 2012 at 8:52 PM, Mark Miller <[email protected]> wrote: >> I think we should start whatever our next release is very soon. >> >> Given some of the SolrCloud issues, I'd like to do a 4.0.1 personally. But >> the issues are not data loss issues, so I could be convinced that 4.1 is >> fine. But I feel that means less people will move quickly from 4.0 in that >> case, and I don't like it. > > Again I disagree, but I'll make my argument mainly from a release > engineering perspective. > > Its simple: > 4.1 exists today, jenkins is kicking the shit out of it, if we made a > good RC it could maybe even pass. > 4.0.1 does not yet exist!, i dont really see bugfixes backported to > lucene_solr_4_0_0 branch. If we made a flurry of backports, this would > likely create bugs that 4.1 doesnt have. > > so 4.1 will be a more stable, more reliable release for these reasons. > It has nothing to do with how important bugs are or anything. creating > a 4.0.1 from scratch is work that i'm not interested in doing (even as > a bugfixer backporting bugs i have fixed, 4.1 is a more efficient > investment here). --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
