major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].
Meanwhile we could also release 7.2.3 [2] (7.2.2 has been released in
16/9/2017). In March or later (see overall of changes [3]), what do
you think?
On Tue, Feb 27, 2018 at 10:14 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].
That's good. Perhaps even earlier? Because I would like to see a new
release with ZSTD compression included since I cannot run trunk in
production and hesitate to heavily patch 7.4. locally. That would be
7.6.0 then.
Yet some backports are open for 7.4.1 [4]
Meanwhile we could also release 7.2.3 [2] (7.2.2 has been released in
16/9/2017). In March or later (see overall of changes [3]), what do
you think?
Yes, a new 7.2.3 release soon as well. Yesterday I submitted a fix it
since it failed to compile on Fedora 28. Some other distros should be
tested as well before releasing (however, that does not take ages).
Maybe that would become the last 7.2.x then? We'll see.
Also some backports are desired here: [5]
While we are at it, I would also package up without big marketing hype
a new 7.0.6 release [6], just to make it an official tarball. It
contains some updates you don't want to miss if still using 7.0 for
whatever reason.
I hope that the non-functional digitizer and semi-functional pull-down control can be fixed for Mac.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].
That’s good. Perhaps even earlier? Because I would like to see a new
release with ZSTD compression included since I cannot run trunk in
production and hesitate to heavily patch 7.4. locally. That would be
7.6.0 then.
Yet some backports are open for 7.4.1 [4]
Meanwhile we could also release 7.2.3 [2] (7.2.2 has been released in
16/9/2017). In March or later (see overall of changes [3]), what do
you think?
Yes, a new 7.2.3 release soon as well. Yesterday I submitted a fix it
since it failed to compile on Fedora 28. Some other distros should be
tested as well before releasing (however, that does not take ages).
Maybe that would become the last 7.2.x then? We’ll see.
Also some backports are desired here: [5]
While we are at it, I would also package up without big marketing hype
a new 7.0.6 release [6], just to make it an official tarball. It
contains some updates you don’t want to miss if still using 7.0 for
whatever reason.
On Tue, Feb 27, 2018 at 11:30 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Feb 27, 2018 at 10:14 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].
That's good. Perhaps even earlier? Because I would like to see a new
release with ZSTD compression included since I cannot run trunk in
production and hesitate to heavily patch 7.4. locally. That would be
7.6.0 then.
Indeed we may create a new 7.6 branch already earlier and phase out 7.2.
Yet some backports are open for 7.4.1 [4]
Meanwhile we could also release 7.2.3 [2] (7.2.2 has been released in
16/9/2017). In March or later (see overall of changes [3]), what do
you think?
Yes, a new 7.2.3 release soon as well. Yesterday I submitted a fix it
since it failed to compile on Fedora 28. Some other distros should be
tested as well before releasing (however, that does not take ages).
Maybe that would become the last 7.2.x then? We'll see.
Also some backports are desired here: [5]
For 7.2.3, I see only these relevant candidates left:
* i18N: Install gettext to Python script modules to use translated
strings extracted by r70817: r70818
* r.grow.distance: clean up after r68611: r69327
As Martin wrote: the authors in trunk may judge (here: Maris and
Vaclav, respectively).
2018-03-04 20:59 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
For 7.2.3, I see only these relevant candidates left:
* i18N: Install gettext to Python script modules to use translated
strings extracted by r70817: r70818
It is useless to backport r70818 without r70817. And both are
questionable, as someone would have to merge translations from trunk
to 7.2 as there are no translations for newly extracted strings in 7.2
and Transifex points to (whatever but it is not 7.2).
I tend to say - no backport for this one.
On Sun, Mar 4, 2018 at 3:39 PM, Maris Nartiss <maris.gis@gmail.com> wrote:
2018-03-04 20:59 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
> For 7.2.3, I see only these relevant candidates left:
>
> * i18N: Install gettext to Python script modules to use translated
> strings extracted by r70817: r70818
It is useless to backport r70818 without r70817. And both are
questionable, as someone would have to merge translations from trunk
to 7.2 as there are no translations for newly extracted strings in 7.2
and Transifex points to (whatever but it is not 7.2).
I tend to say - no backport for this one.
Any particular reason not to use the "import underscore" mechanism used in
wxGUI utils.py/globalvar.py/gcmd.py in r70818? It was little rough to
introduce it (r57219 & r57220, #1739#comment:5), but AFAIK it is the
recommended way and it seems to work well.
2018-03-05 23:15 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
I created a draft for 7.4.1 and added recently backported new features
of Graphical Modeler [1]. Please free to update the draft by adding
cool features implemented by you Ma
2018-02-27 22:14 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].
[1] https://trac.osgeo.org/grass/milestone/7.4.1
I would propose based on planned time schedule soft freeze starting by
tomorrow (Mon 26/3). Martin
Am 25. März 2018 12:32:24 MESZ schrieb Martin Landa <landa.martin@gmail.com>:
Dear all,
2018-02-27 22:14 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].
[1] https://trac.osgeo.org/grass/milestone/7.4.1
I would propose based on planned time schedule soft freeze starting by
tomorrow (Mon 26/3).
Ma