+1 I've observed only a few issues so far, and all of them have been resolved.
Thanks, Okumin On Fri, Jan 31, 2025 at 6:07 PM László Bodor <bodorlaszlo0...@gmail.com> wrote: > > 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 <dev@tez.apache.org> <dev@tez.apache.org> > > Cc user<u...@tez.apache.org> , > > <u...@tez.apache.org> dev<dev@tez.apache.org> <dev@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 | dev@tez.apache.org、u...@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 > > > >
