Hi,
I am a bit concerned that devbr6 r39128 "Added code to
automatically choose an appropriate geometry type for output."
breaks backwards compatibility with earlier grass 6.x. (creates
different output from same script)
but I don't know much about what the before/after issue looks
like here to be sure. of course for grass7 it is fine to change
behaviour if it's an improvement.
comments?
thanks,
Hamish
Hi,
2009/9/11 Hamish <hamish_b@yahoo.com>:
I am a bit concerned that devbr6 r39128 "Added code to
automatically choose an appropriate geometry type for output."
breaks backwards compatibility with earlier grass 6.x. (creates
different output from same script)but I don't know much about what the before/after issue looks
like here to be sure. of course for grass7 it is fine to change
behaviour if it's an improvement.comments?
probably should be reverted in devbr6, trunk is fine. This feature
breaks backwards compatibility, moreover it's debatable what should go
to devbr6. We should be more focus on GRASS 7.0. Very rough roadmap
(my POV):
6.4 (~10/2009)
6.5 (~03/2010)
7.0 (~06/2011)
Thanks Benjamin for great work!
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin wrote:
it's debatable what should go to devbr6. We should be more focus
on GRASS 7.0. Very rough roadmap (my POV):6.4 (~10/2009)
6.5 (~03/2010)
7.0 (~06/2011)
my 2c pov:)
6.4.0: closed for new features, critical bug fixes only.
6.4.1: add a couple of features already in 6.5 and intended for 6.4
but not well enough tested for backport today. (those with tickets
who missed the train, but don't sell any new tickets)
Otherwise normal bug fixes only.
6.4.2+: critical bug fixes only.
it is tempting to allow things like an improved wxNviz, maybe we could
be more relaxed with GUI vs. more strict with modules/libs. but at the
same time it pays to be strict with a full critical-bug-fix-only freeze
sooner rather than later.
no deep changes or refactoring should go into devbr6. (6.5)
except in extraordinary circumstances all 6.x should be backwards
compatible (at the module CLI level) in usage and behaviour with all
earlier 6.x. Interactive features (ie GUI) does not have to be as
strict because it can't be scripted/requires human decisions.
6.4.0 (~10/2009)
6.4.1 (~12/2009)
6.4.2 (~2/2010)
6.4.3 (as needed)
6.5 not a release branch; just a useful dead-end.
"GRASS 6.5 (restricted development; testbed for backporting, more...)
Utility version for developers, only available as source code."
(and power users/part-devels who need some stability)
6.5.0 devel. preview release (only if this time next year 7.0 isn't out yet)
7.0 when it's ready. let's worry about release dates for it after 6.4.
H
On Sep 12, 2009, at 4:24 AM, Hamish wrote:
Martin wrote:
it's debatable what should go to devbr6. We should be more focus
on GRASS 7.0. Very rough roadmap (my POV):6.4 (~10/2009)
6.5 (~03/2010)
7.0 (~06/2011)my 2c pov:)
6.4.0: closed for new features, critical bug fixes only.
6.4.1: add a couple of features already in 6.5 and intended for 6.4
but not well enough tested for backport today. (those with tickets
who missed the train, but don't sell any new tickets)
Otherwise normal bug fixes only.
6.4.2+: critical bug fixes only.
I agree with this, I just have one question:
where do the current somewhat broken items in nviz belong in your list,
I am talking about
1. fixing sites with attributes handling (I think Maris has
been looking into it but I am not sure how difficult it is to fix it)
2. nviz crashing or freezing with reclassed raster (it should at least give
an error message and exit) - there was some discussion about it -
64bit issue? but I am not sure whether it was fixed
3. and a minor but annoying thing that nviz won't start from wxGUI (under File>NVIZ)
in winGRASS
Should we consider things that worked in 63 but don't work now critical?
Even if only few people may use them?
it is tempting to allow things like an improved wxNviz, maybe we could
be more relaxed with GUI vs. more strict with modules/libs. but at the
same time it pays to be strict with a full critical-bug-fix-only freeze
sooner rather than later.no deep changes or refactoring should go into devbr6. (6.5)
except in extraordinary circumstances all 6.x should be backwards
compatible (at the module CLI level) in usage and behaviour with all
earlier 6.x. Interactive features (ie GUI) does not have to be as
strict because it can't be scripted/requires human decisions.6.4.0 (~10/2009)
6.4.1 (~12/2009)
6.4.2 (~2/2010)
6.4.3 (as needed)
this is a good schedule, by the end of October we should be through
most of raster functionality in the class giving RC5 a good test run.
But we are not doing much v* and i* stuff and no db stuff - maybe we
should ask on users list to get it broadly tested, or somebody is teaching
class with more vector topics that could serve as testing ground?
Helena
6.5 not a release branch; just a useful dead-end.
"GRASS 6.5 (restricted development; testbed for backporting, more...)
Utility version for developers, only available as source code."
(and power users/part-devels who need some stability)6.5.0 devel. preview release (only if this time next year 7.0 isn't out yet)
7.0 when it's ready. let's worry about release dates for it after 6.4.
H
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena wrote:
where do the current somewhat broken items in nviz belong in your list,
I am talking about1. fixing sites with attributes handling (I think Maris
has been looking into it but I am not sure how difficult it is
to fix it)2. nviz crashing or freezing with reclassed raster (it
should at least give an error message and exit) - there was some
discussion about it - 64bit issue? but I am not sure whether it was
fixed3. and a minor but annoying thing that nviz won't start
from wxGUI (under File>NVIZ) in winGRASS
Should we consider things that worked in 63 but don't work
now critical?
Even if only few people may use them?
the term "critical" might be a bit hyperbolic, but I think the general
idea is just to go through an extra mental step and ask yourself if the
change is really a big deal or not, and coupled to that how much of a
dent it could cause to other things if it contained some unintended
consequence. A minor tcl edit probably isn't going to cause stability
problems to the wider system for example, but as we saw with #654 in
rc5 a seemingly innocent change to libgis can.
To me, File->NVIZ not working in the WinGrass wxGui is a fairly major
bug. New users don't have (obvious) access to one of our flagship
components. The cause of one is still a complete mystery to me.
Also, there seems to be something more needed than just PATHEXT for
v.type and g.gui wrappers.
To me, nviz crashing on reclass maps is a medium priority bug; but I
wouldn't stall 6.4.0 for it. For the record it does seem to exit with
an error, even if that message isn't all that helpful.
Sites with attributes is a regression, but the positive side of that
is that we can checkout by date and narrow it down to the exact commit
that broke it (someone has already done that?) so not a complete mystery.
If clear bugfixes are available I don't really object to backporting
them, it's just trying to avoid the trap of rushing in all the unfinished
business before the deadline, which leads to untested code & a poor
release. The other thing to watch out for is cosmetic edits to strings
just before release. All 10-20 translations then need to be redone but
it's too late...
2c more,
Hamish
Short note on nviz attributes - I suggest to NOT revert change that
broke this feature. I'm currently revriting attribute code, but I have
stuck in real life (work/family) and thus it will not be ready atleast
for next two weeks. It requires some redesign in OGSF, still I hope it
will be usefull also for 7.
Maris on run.