After a long time of development and many, many improvements, it is
time to release 8.3.0.
Version scheme update: please note that we abandon the odd/even scheme
and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
series. See also the related RFC: Version Numbering
(https://github.com/OSGeo/grass/pull/2357).
El vie, 17 feb 2023 a las 15:25, Markus Neteler (<neteler@osgeo.org>) escribió:
Hi devs,
After a long time of development and many, many improvements, it is
time to release 8.3.0.
Version scheme update: please note that we abandon the odd/even scheme
and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
series. See also the related RFC: Version Numbering
(https://github.com/OSGeo/grass/pull/2357).
Just wondering… Should we adopt an RFC that has not yet been merged nor approved via motion? There’s a list of tasks in the PR that still seems incomplete and I see that Vashek moved the milestone of the RFC to 8.4… I’m not trying to delay the release -either it is called 8.3 or 8.4, it is overdue- but IMO we need to agree on the RFC, no? Shall I prepare a motion and we approve a version 1 of the Version Numbering RFC?
On Tue, Feb 21, 2023 at 7:19 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi Markus,
El vie, 17 feb 2023 a las 15:25, Markus Neteler (<neteler@osgeo.org>) escribió:
Hi devs,
After a long time of development and many, many improvements, it is
time to release 8.3.0.
Version scheme update: please note that we abandon the odd/even scheme
and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
series. See also the related RFC: Version Numbering
(https://github.com/OSGeo/grass/pull/2357).
Just wondering.. Should we adopt an RFC that has not yet been merged nor approved via motion? There's a list of tasks in the PR that still seems incomplete and I see that Vashek moved the milestone of the RFC to 8.4...
Not sure why a RFC should be related to a release milestone?
I'm not trying to delay the release -either it is called 8.3 or 8.4, it is overdue-
Overdue, yes.
but IMO we need to agree on the RFC, no? Shall I prepare a motion and we approve a version 1 of the Version Numbering RFC?
Yes, let's get this RFC approved and then follow our plan.
El vie, 17 feb 2023 a las 15:25, Markus Neteler (<neteler@osgeo.org>) escribió:
Version scheme update: please note that we abandon the odd/even scheme
and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
series. See also the related RFC: Version Numbering
(https://github.com/OSGeo/grass/pull/2357).
Just wondering… Should we adopt an RFC that has not yet been merged nor approved via motion? There’s a list of tasks in the PR that still seems incomplete and I see that Vashek moved the milestone of the RFC to 8.4… I’m not trying to delay the release -either it is called 8.3 or 8.4, it is overdue- but IMO we need to agree on the RFC, no? Shall I prepare a motion and we approve a version 1 of the Version Numbering RFC?
Ideally, yes, but practically we can follow it already. We agreed at the PSC meeting that we want to follow it, although we did not vote on actually approving it because it was not finished. We also don’t have any formal procedure for numbering except tradition. There were also no negative comments for the PR in the PR itself. Hence, the RFC in the PR is the closest thing to an official guidance we have.
We are using the yet-unmerged Python version RFC in a similar way.
The version numbering PR did not make it through my triage when I was cleaning PRs and issues before the release because it did not pass my rule “ready or important to have in the 8.3 code”.
I still agree that it is a potentially big change for those who actually followed the version numbering, but I hope if there is some criticism of that, we would know already.
otrd., 2023. g. 21. febr., plkst. 21:11 — lietotājs Vaclav Petras
(<wenzeslaus@gmail.com>) rakstīja:
I still agree that it is a potentially big change for those who actually followed the version numbering, but I hope if there is some criticism of that, we would know already.
Or simply they don't know yet that 8.3 will not be a development
testing version Before announcement of upcoming 8.3.0 release it
was not even communicated to the -dev ML.
In practice though I do agree – most likely nobody cares about version
numbers anyway.
Markus Neteler <neteler@osgeo.org> schrieb am Fr., 17. Feb. 2023, 19:24:
Hi devs,
After a long time of development and many, many improvements, it is
time to release 8.3.0.
Version scheme update: please note that we abandon the odd/even scheme
and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
series. See also the related RFC: Version Numbering
(https://github.com/OSGeo/grass/pull/2357).
On Fri, Mar 17, 2023 at 11:41 AM Markus Neteler <neteler@osgeo.org> wrote:
Markus Neteler <neteler@osgeo.org> schrieb am Fr., 17. Feb. 2023, 19:24:
Hi devs,
After a long time of development and many, many improvements, it is
time to release 8.3.0.
Version scheme update: please note that we abandon the odd/even scheme
and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
series. See also the related RFC: Version Numbering
(https://github.com/OSGeo/grass/pull/2357).
Still open PRs. Please complete them or bump them to the next milestone.
Now just a few are remaining:
- Suppress compiler warnings from GDAL #2899, nilason
- t.register: support mapset name in input file #2863, ninsbl
- g.extension: fix getting addons path if input JSON file doesn't
exist #2717, tmszi
- i.vi: support soil_line_slope for PVI #2561, pesekon2
- libproj: simple check for area of use #2519, metzm
- temporal dbif for current mapset only #2448, metzm
- g.extension: better handle request exceptions for l flag #2203, tmszi
We merged remaining open PRs, so we are at 0 open PRs!
Today Vashek and I have created the new "releasebranch_8_3" in GitHub.
Means: we need to backport fixes from main as appropriate and setup
new cronjobs for grass.osgeo.org.
RC1 has been released 2 weeks ago. Is there anything missing in order to release 8.3.0 (what be nice to do for FOSS4G).
Yes, let’s release asap.
As there was no negative feedback, I’d suggest to release this week.
If there are no objections, I could do that eg later tonight.
út 20. 6. 2023 v 8:49 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
RC1 has been released 2 weeks ago. Is there anything missing in order to release 8.3.0 (what be nice to do for FOSS4G).
Yes, let’s release asap.
As there was no negative feedback, I’d suggest to release this week.
If there are no objections, I could do that eg later tonight.
should probably be backported too, as it significantly improves the user experience with g.extension. it is a tiny change in code, so a new RC is probably not necessary for that?
On Tue, Jun 20, 2023 at 9:03 AM Sebastiaan Couwenberg
<sebastic@xs4all.nl> wrote:
On 6/20/23 08:46, Martin Landa wrote:
> RC1 has been released 2 weeks ago. Is there anything missing in order to
> release 8.3.0 (what be nice to do for FOSS4G).
Was there no announcement for RC1?
Apologies, this fell off the radar due to heavy changes in the (now
automated) release management and travelling back from the Community
meeting.
Thanks for that.
But is this now a blocker for the release?
If merged, do we need RC2?
From Mac point of view, this does not necessitate a RC2 (in this case). The fix is mainly GUI cosmetics, and doesn’t seem to (even) potentially break anything.
Before announcement of upcoming 8.3.0 release it