the fact that other projects stay un the minor version to 'allow' incompat changes whenever they want, well it is a matter of those projects and their communities.
i'm proud that oozie has a great track of record in that front, including among (yes among, not only between) major versions. and we should keep it that way. regarding db schema upgrades, until now we were saying that it should be only in major upgrades. given the fact that the dbtools manages upgrades in a very unpainful way, and this has happened for a while now, i think it should be fine for a minor release to require a dbtool run. we just have to make sure this is documented, and that if the db has not been upgraded the new oozie does not start (which i think it is already happening) thx Alejandro (phone typing) > On May 14, 2014, at 16:48, Robert Kanter <rkan...@cloudera.com> wrote: > > During the 3.x releases, we had an optional database change for MySQL to > change TEXT to MEDIUMTEXT; I don't think there was a required one, but I > don't remember. > > In any case, that's a good point about the other projects and how they > handle these things. So I'd agree then that we can have a database > upgrade. Bowen, please make sure to verify that the database upgrade works > for 2.x to 4.1, 3.x to 4.1, and 4.0 to 4.1 and for each type. > > > On Wed, May 14, 2014 at 11:07 AM, Rohini Palaniswamy < > rohini.adi...@gmail.com> wrote: > >> Not sure. I remember someone mentioning that schema upgrade should have >> major version incremented in case of Oozie. But there was one release (3.1 >> ->3.2 or something before I started working on Oozie) which had schema >> change just incrementing minor version. If there was an already agreed >> procedure we should follow that else I am fine either way and ok going with >> 4.1 (as long it is atleast minor version and not patch version that we are >> changing) considering every other hadoop project still have major version >> as 0 and only keep updating minor version. For eg: hive 0.12 -> 0.13 is a >> major release with schema changes. If we keep incrementing major version >> very often it feels slightly weird when comparing to other hadoop projects >> which are still in 0.x :). >> >> >> On Tue, May 13, 2014 at 3:22 PM, Robert Kanter <rkan...@cloudera.com> >> wrote: >> >>> I agree; we'd also have to likely make two versions of each patch going >>> forward for 4.x and 5.x/trunk otherwise. >>> But are we "allowed" to make Oozie 4.0.x --> 4.1.0 require a database >>> upgrade? >>> >>> >>> On Tue, May 13, 2014 at 2:30 PM, Rohini Palaniswamy < >>> rohini.adi...@gmail.com >>>> wrote: >>> >>>> It might be tough work as the CLOB->BLOB conversion change touches a >> lot >>> of >>>> classes. >>>> >>>> >>>> On Sun, May 11, 2014 at 9:25 PM, Robert Kanter <rkan...@cloudera.com> >>>> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> Should we start thinking about a 4.1.0 release? It's been a while >>> since >>>>> 4.0.0 (4.0.1 was to fix some critical things like not being able to >>>>> compile) and I think we have about 200 additional JIRAs in master. >>>>> >>>>> Are there any specific features that we'd want to put in 4.1.0 and >> wait >>>>> for? >>>>> >>>>> Another thing to keep in mind is that we can't just take everything >> in >>>>> master; I forget what exactly, but there's some JIRAs that change the >>>>> database that we'll have to save for 5.0.0. >>>>> >>>>> Does anybody want to volunteer to drive the 4.1.0 release? >>>>> >>>>> >>>>> thanks >>>>> - Robert >>
