+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
