according to our plans we should start to prepare the initial 7.6.0 release:
https://trac.osgeo.org/grass/milestone/7.6.0
- Proposal of release: ~14 May
- Soft freeze of release branch: ~23 May
- RC1: ~23 June
- RC2: ~7 July
- Final release: ~29 July 2018 - GRASS GIS birthday!
In addition, we could make it into the upcoming OSGeoLive 12 being
prepared for the FOSS4G 2018 (see below).
IMHO we have definitely accumulated enough new new features. The next
step would be to create a release branch and shift the attention to
the new branch accordingly.
Strong opinions against it?
Markus
---------- Forwarded message ----------
From: Angelos Tzotsos <gcpp.kalxas@gmail.com>
Date: Mon, Jun 11, 2018 at 5:16 PM
Subject: [OSGeo-Discuss] [OSGeoLive] OSGeoLive 12.0 status: alpha1
To: Osgeolive <osgeolive@lists.osgeo.org>, OSGeo Discussions
<discuss@lists.osgeo.org>
Hi all,
The OSGeoLive team is working hard to get the next version ready for
FOSS4G 2018.
[...]
New projects are still welcome to join, since our feature freeze is July 2nd.
On Sun, Jun 17, 2018 at 5:24 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Jun 11, 2018 at 6:07 PM, Markus Neteler <neteler@osgeo.org> wrote:
> Hi devs,
>
> according to our plans we should start to prepare the initial 7.6.0
release:
>
> https://trac.osgeo.org/grass/milestone/7.6.0
What needs to be fixed in _trunk_ first before branching
"releasebranch_7_6/" ?
The two following enhancement tickets would be really good to resolve
before 7.6 (branch or at least release) since it requires CLI API to be
consolidated. #3586 is a blocker because it needs an API change (new API
which is now in trunk, 7.5) and #3585 would be good to have resolved before
this new API is publicized (it suggests to simplify it at the cost of
duplication or potential confusion).
#3585 Don't require -c for --tmp-location #3586 Add XY location to grass command interface
What needs to be fixed in _trunk_ first before branching "releasebranch_7_6/" ?
I would love to see https://trac.osgeo.org/grass/ticket/3348 fixed as it makes working in a combination of terminal and GUI quite annoying because of the GTK messages flooding the terminal.
I just added a comment to this ticket as I think one of the issues is the position of the "Render" checkbox.
Don't know if this is enough of an issue to keep us from branching, or if this can be backported to the 7.6 branch once it is fixed in trunk.
On Tue, Jun 26, 2018 at 10:33 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
On Sun, Jun 17, 2018 at 5:24 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Jun 11, 2018 at 6:07 PM, Markus Neteler <neteler@osgeo.org>
wrote:
> Hi devs,
>
> according to our plans we should start to prepare the initial 7.6.0
release:
>
> https://trac.osgeo.org/grass/milestone/7.6.0
What needs to be fixed in _trunk_ first before branching
"releasebranch_7_6/" ?
The two following enhancement tickets would be really good to resolve
before 7.6 (branch or at least release) since it requires CLI API to be
consolidated. #3586 is a blocker because it needs an API change (new API
which is now in trunk, 7.5) and #3585 would be good to have resolved before
this new API is publicized (it suggests to simplify it at the cost of
duplication or potential confusion).
#3585 Don't require -c for --tmp-location #3586 Add XY location to grass command interface
#3348 or other bugs or annoyances don't prevent us from branching as they
don't involve large code changes which would make subsequent backports
impossible nor they are API changes which could lead to bad legacy APIs or
API breaks.
There are no tickets marked as blocker or critical and there is only 8
defect tickets.
Additionally, the `grass --tmp-location` flag is probably (hopefully)
addition useful enough to make for next minor release. (Forgive me for not
recalling other changes.) [Side note: I'm saying this because I just saw a
note somewhere complaining that now software is released based on different
occasions not when it is ready for the next version. In our case, we missed
the birthday date, but we have features and fixes!]
#3348 or other bugs or annoyances don't prevent us from branching as they don't involve large code changes
which would make subsequent backports impossible nor they are API changes which could lead to bad legacy APIs or API breaks.
ok.
There are no tickets marked as blocker or critical and there is only 8 defect tickets.
On Mon, Nov 26, 2018 at 11:30 PM Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Nov 10, 2018 at 11:38 AM Markus Neteler <neteler@osgeo.org> wrote:
>
> Hi devs,
>
> we should remember to start to prepare the initial 7.6.0 release:
>
> https://trac.osgeo.org/grass/milestone/7.6.0
... I shifted the dates a bit but not sure if the dates make sense.
(Importantly, we should focus on 7.8.x soon to get the Python3 support out)
Since we are way behind schedule, I'll tag 7.6.0 RC1 in the next days.
On Mon, Dec 24, 2018 at 10:41 AM Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Nov 26, 2018 at 11:30 PM Markus Neteler <neteler@osgeo.org> wrote:
> On Sat, Nov 10, 2018 at 11:38 AM Markus Neteler <neteler@osgeo.org> wrote:
> >
> > Hi devs,
> >
> > we should remember to start to prepare the initial 7.6.0 release:
> >
> > https://trac.osgeo.org/grass/milestone/7.6.0
>
> ... I shifted the dates a bit but not sure if the dates make sense.
>
> (Importantly, we should focus on 7.8.x soon to get the Python3 support out)
Since we are way behind schedule, I'll tag 7.6.0 RC1 in the next days.
st 26. 12. 2018 v 13:22 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
there are some "hot" issues [1,2] targeted to 7.6.0, but they need
some discussion. To avoid postponing 7.6.0 release I would vote for
RC2 on time (26/12+14 days-> now:-)
On Sat, Jan 12, 2019 at 12:41 PM Martin Landa <landa.martin@gmail.com> wrote:
st 26. 12. 2018 v 13:22 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
there are some "hot" issues [1,2] targeted to 7.6.0, but they need
some discussion. To avoid postponing 7.6.0 release I would vote for
RC2 on time (26/12+14 days-> now:-)
I am all for it!
Do we really need a RC2? I checked the post-RC1 changes and cannot see
anything untested.