It seems ok to change them in a source and binary compatible way. +1 to making upgrades as easy as switching out the jars at runtime.
Alan. On Fri, Aug 4, 2017 at 3:00 PM, Dain Sundstrom <[email protected]> wrote: > > > On Aug 4, 2017, at 2:51 PM, Owen O'Malley <[email protected]> > wrote: > > > > On Fri, Aug 4, 2017 at 12:15 PM, Alan Gates <[email protected]> > wrote: > > > >> Let me make sure I have the backwards compatibility straight. If a user > >> switches to ORC 2.0, he could choose to continue writing in older > formats > >> so that his old tools could read it. Then once all his tools are > upgraded > >> he could throw a config switch and new data would be written in the new > >> format. Once that switch was thrown, any pre-ORC 2.0 tools would be > >> unusable. Before throwing that switch, he would get none of the > benefits > >> of ORC 2.0. Is this summary correct? > >> > > > > Yes, exactly. > > I think the important part is not to change the APIs so tools can be > updated by just upgrading the dep. > > -dain
