On Thu, Feb 18, 2010 at 5:19 PM, Jeff Hammerbacher <[email protected]> wrote: > Thanks Owen, that's useful information. It sounds like the API > incompatibility vote can be a separate issue. > > Do we have consensus around rebasing on 0.21? Anyone already testing on 0.21 > who would be upset if the current branch were to be retired? >
One question I have is what to do with the JIRA tickets - we probably need some kind of bulk edit, right? Anything that's currently resolved with fix version 22 needs to be changed over to fix version 21? > On Thu, Feb 18, 2010 at 5:02 PM, Owen O'Malley <[email protected]> wrote: > >> On Feb 18, 2010, at 3:06 PM, Jeff Hammerbacher wrote: >> >> I think the community will step up to knock down some of the >>> blockers once we resolve what should be in the 0.21 release: the current >>> branch, or a rebase on trunk. Do you/Yahoo! have a preference on that >>> front? >>> >> >> Yahoo doesn't care. Even if we rebase the 0.21 branch, because of the >> timing, Yahoo will probably never deploy it. (It take months to push a >> release through QA and production testing, as I wrote the security release >> will hit the pipeline this year (code complete in february, first >> integration cluster in april, on all production clusters by august). Yahoo >> can't handle another big release until january 2011. >> >> Personally, I'd prefer to rebase 0.21, especially after we have the Maven >> story straightened out. Generating good poms would be a huge win for >> downstream projects. >> >> One big concern is that backwards incompatibility is a big cost. Especially >> if 0.21 (like 0.19) never gets wide deployment, I'd like to start a vote >> that we don't make any API incompatible in 0.22 relative to 0.20. >> >> -- Owen >> >
