since GRASS 7.0.0 has been released almost two mounts ago (28/12) we
should plan 7.2.1 release. Our goal is to release at least twice or in
better case three times per year. Currently 7.2.1 release is planned
in April [1]. It would mean regarding RFC4 [2]:
3/3 - soft freeze (only bugfixes)
3/4 - hard freeze + RC1
17/4 - RC2
24/4 - final
Any comments?
It would be nice also to solve waiting backports [3] till 3/3.
since GRASS 7.0.0 has been released almost two mounts ago (28/12) we
should plan 7.2.1 release. Our goal is to release at least twice or in
better case three times per year. Currently 7.2.1 release is planned
in April [1]. It would mean regarding RFC4 [2]:
3/3 - soft freeze (only bugfixes)
3/4 - hard freeze + RC1
17/4 - RC2
24/4 - final
Any comments?
+1
It would be nice also to solve waiting backports [3] till 3/3.
Most of these are not bugfixes, but enhancements. I don't think they should go into a point release. I'd rather we only fix bugs in point releases and get out 7.4 rather quickly if we feel there are enough enhancements.
On Mon, Feb 20, 2017 at 11:07 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 20/02/17 10:03, Martin Landa wrote:
Hi all,
since GRASS 7.0.0 has been released almost two mounts ago (28/12) we
should plan 7.2.1 release. Our goal is to release at least twice or in
better case three times per year. Currently 7.2.1 release is planned
in April [1]. It would mean regarding RFC4 [2]:
3/3 - soft freeze (only bugfixes)
3/4 - hard freeze + RC1
17/4 - RC2
24/4 - final
Any comments?
+1
Yes (or we even speed up, perhaps no need to wait for so long).
It would be nice also to solve waiting backports [3] till 3/3.
Most of these are not bugfixes, but enhancements. I don't think they should
go into a point release. I'd rather we only fix bugs in point releases and
get out 7.4 rather quickly if we feel there are enough enhancements.
since GRASS 7.0.0 has been released almost two mounts ago (28/12) we
should plan 7.2.1 release. Our goal is to release at least twice or in
better case three times per year. Currently 7.2.1 release is planned
in April [1]. It would mean regarding RFC4 [2]:
3/3 - soft freeze (only bugfixes)
3/4 - hard freeze + RC1
17/4 - RC2
24/4 - final
Any comments?
+1
Yes (or we even speed up, perhaps no need to wait for so long).
It would be nice also to solve waiting backports [3] till 3/3.
Most of these are not bugfixes, but enhancements. I don’t think they should
go into a point release. I’d rather we only fix bugs in point releases and
get out 7.4 rather quickly if we feel there are enough enhancements.
2017-02-20 11:07 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:
Most of these are not bugfixes, but enhancements. I don't think they should
go into a point release. I'd rather we only fix bugs in point releases and
get out 7.4 rather quickly if we feel there are enough enhancements.
I fully agree, but what realistically means "quickly"? In good case I
would say one and half year after 7.2.0 release. It means
spring/summer 2018. Eg.
* 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)
From this perspective also small improvements could go to release
branch I would say. Currently we are trying to have 2-3 point release
per year. It means about 4 months release cycle. Lets say:
* first two months - waiting backports (traced at [1]) + small improvements
* second two months - only bugfixes, other backports recorded at [1] -
RFC4 on the road [2]
Note: all backports should be referenced by trac issue if possible
* 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
2017-02-26 20:33 GMT+01:00 Helmut Kudrnovsky <hellik@web.de>:
spring 2017 - 7.4.0
autumn 2017 - 7.4.1
7.4.0 in spring 2017??? You probably meant spring 2018?
Last release is 7.2.0 (Dec 2016), we even haven't released 7.2.1. It's
always harder to release 7.x.0 than point releases, like 7.2.x. So
less releases do not really help.
Preparing 7.4.0 will take longer time, we need to prepare major
release news, create release branch and so on. A lot of work. Moreover
release branch should be created in advance, I guess ~ 5 months before
release.
2017-02-26 20:33 GMT+01:00 Helmut Kudrnovsky <hellik@web.de>:
spring 2017 - 7.4.0
autumn 2017 - 7.4.1
7.4.0 in spring 2017??? You probably meant spring 2018?
Last release is 7.2.0 (Dec 2016), we even haven’t released 7.2.1. It’s
always harder to release 7.x.0 than point releases, like 7.2.x. So
less releases do not really help.
+1
IMHO more releases do help, e.g more frequent 7.2.x releases with bug fixes.
Preparing 7.4.0 will take longer time, we need to prepare major
release news, create release branch and so on. A lot of work. Moreover
release branch should be created in advance, I guess ~ 5 months before
release.
There must be a good reason to release a new GRASS 7 branch, e.g. some new exciting features or bug fixes that because of their complexity could not be backported.
On Sun, Feb 26, 2017 at 8:57 PM, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>> wrote:
2017-02-26 20:33 GMT+01:00 Helmut Kudrnovsky <hellik@web.de
<mailto:hellik@web.de>>:
> spring 2017 - 7.4.0
> autumn 2017 - 7.4.1
7.4.0 in spring 2017??? You probably meant spring 2018?
Last release is 7.2.0 (Dec 2016), we even haven't released 7.2.1. It's
always harder to release 7.x.0 than point releases, like 7.2.x. So
less releases do not really help.
+1
IMHO more releases do help, e.g more frequent 7.2.x releases with bug fixes.
This is exactly the question: only bug fixes, or also small improvements as Martin suggests.
Preparing 7.4.0 will take longer time, we need to prepare major
release news, create release branch and so on. A lot of work. Moreover
release branch should be created in advance, I guess ~ 5 months before
release.
There must be a good reason to release a new GRASS 7 branch, e.g. some
new exciting features or bug fixes that because of their complexity
could not be backported.
I think we should not place the expectations to high to minor release versions. Especially if point releases are bug fixes only, then I think that we should have more minor version releases with improvements, even if they are more incremental than really exciting new features...
I ask myself the question of this schedule is appropriate for point
releases. Maybe 1 month between soft and hard freeze is a lot ?
…
do you agree to change it from 30 to 20 days or even 14 days [1]? Ma
+1 for 14 days.
+1 for 14 days.
I suppose that the trac page can be edited right away since it is a draft anyway.
We are getting close to RC1, please check what else to be backported. Authors pls take care yourself (or I happily backport :p)
