+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
