Thanks, everyone, for the feedback! I believe we cannot afford to skip a stable release in the *0.10.x* line since we don't know exactly what might break in *1.0.0*.
Tez is already *JDK17* runtime-compatible, provided certain *add-opens/add-exports* arguments are configured (which can be handled through Hive). To clarify, this refers only to runtime compatibility: compiling on *JDK8* and running on *JDK17*. Butao Zhang <butaozha...@163.com> ezt írta (időpont: 2024. dec. 31., K, 14:16): > +1 > > I even think we could just release the 1.0.0 version of TEZ including > jdk17, instead of releasing the 0.10.5 release. > > IMO, Tez was already a mature execution engine, but the 0.x version > number gave users the impression that Tez was not stable enough. So it's > time to use version number 1.0. > For the JDK17, i think it would be good if we can release the tez version > with JDK17, then we can do the e2e test against Hive4.1.0 & Tez 1.0.0 & > JDK17. > > > Thanks, > Butao Zhang > ---- Replied Message ---- > From Ayush Saxena<ayush...@gmail.com> <ayush...@gmail.com> > Date 12/31/2024 20:21 > To <d...@tez.apache.org> <d...@tez.apache.org> > Cc user<user@tez.apache.org> , > <user@tez.apache.org> dev<d...@tez.apache.org> <d...@tez.apache.org> > Subject Re: [DISCUSS] It's time to break Tez 0.x release line and current > branching scheme > +1 for changing the master to 1.x post the upcoming release. > > We can explore moving the version to JDK-17, like hive is planning for > 4.1.x release and the version bump will safeguard us against any > incompatibilities if any introduced during the process and at the same time > we will have a stable release line which we can release anytime by just > c-picking some major bugs or so if the need be in future. > > -Ayush > > On 31 Dec 2024, at 4:46 PM, lisoda <lis...@yeah.net> wrote: > > +1 > > > > ---- Replied Message ---- > | From | László Bodor<bodorlaszlo0...@gmail.com> | > | Date | 12/31/2024 19:12 | > | To | d...@tez.apache.org、user@tez.apache.org | > | Cc | | > | Subject | [DISCUSS] It's time to break Tez 0.x release line and current > branching scheme | > Hi Team! > > This is not the first time we're about to discuss Tez release versions. > > What we have now is a Tez 0.9.x line that has not been released for years > (and which is told to maintain Hadoop 2 compatibility as far as I can > recall) and the Tez 0.10.x which is the main development line. > It looks strange that we make releases by increasing a patch version > (0.10.1, 0.10.2), although we make ordinary releases (sometimes even with a > *tez-api* change). > > Breaking the 0.10.x release versioning also brings the question of whether > we can make a *Tez 1.0.0*? > It's a common dilemma, whether the project is worth a major bump (I > remember we had been thinking about it in case of Hive 4 too), especially > in the case of the 0->1 transition. *I feel Tez has been ready for 1.x for > a very long time, given its stability in general.* > > My proposal is to: > 1. release 0.10.5 with the current fixes (we have some problems with > 0.10.4) > 2. mark 0.10.x line as a maintenance line > 3. change the master's version to 1.0.0-SNAPSHOT after 0.10.5 > 4. don't hesitate to introduce anything breaking to master before 1.0.0 > (e.g. minimum JDK support, any massive code refactoring) > 5. move to a versioning/branching scheme that makes sense, e.g.: > a) release *1.0.0* (from a release branch *branch-1.0.0 *cut off from > *master* when we're there) > b) then release *1.1.0 *if it's a normal release (cut off from > *master* as *branch-1.1.0 > *when we're there) > c) or release *1.0.1*, if it's a patch release (cut off from *branch-1.0.0 > *as > *branch-1.0.1*) > > Regards, > Laszlo Bodor > >
