>* April 2017 7.2.1 >* September 2017 7.2.2 >* December 2017 7.2.3 >* April 2018 7.2.4 >* May 2018 7.4.0 >* September 2018 7.2.5 (probably last 7.2.x version)
What about simplyfying the release cycle with only 2 fixed releases in a year? spring and fall/autumn with following scheme: spring 2017 - 7.4.0 autumn 2017 - 7.4.1 spring 2018 - 7.6.0 autumn 2018 - 7.6.1 spring 2019 - 7.8.0 autumn 2019 - 7.8.1 spring 2020 - 8.0.0 autumn 2020 - 8.0.1 and so on (with an urgent bugfix release in between if needed) related to our dev man power, 2 releases a year should be enough. with the nice side effect to have a some kind of a "lts" for a year ;-), then after a year the next latest and greatest release will arrive. p.s. me neglecting any release version naming convention :-D ----- best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/release-GRASS-7-2-1-planning-tp5308583p5309569.html Sent from the Grass - Dev mailing list archive at Nabble.com. _______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
