Discussion:
GRASS 6.3.0RC1 released
(too old to reply)
Markus Neteler
2007-10-23 22:31:09 UTC
Permalink
A first release candidate of GRASS 6.3.0 is now available:

http://grass.itc.it/grass63/source/
-> grass-6.3.0RC1.tar.gz

An initial announcement has been drafted at
http://grass.itc.it/announces/announce_grass630.html
(state April 2007, further fixes need to be merged in)

Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.

Release candidate management at
http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan

Please test, test, test...

A big thanks to all contributors!

Markus
Michael Barton
2007-10-24 05:35:03 UTC
Permalink
Markus,

I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?

Michael
Post by Markus Neteler
http://grass.itc.it/grass63/source/
-> grass-6.3.0RC1.tar.gz
An initial announcement has been drafted at
http://grass.itc.it/announces/announce_grass630.html
(state April 2007, further fixes need to be merged in)
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
Release candidate management at
http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan
Please test, test, test...
A big thanks to all contributors!
Markus
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Glynn Clements
2007-10-24 06:03:23 UTC
Permalink
Post by Michael Barton
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.

The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.

To sync changes from the trunk to a branch, use "cvs update" with two
-j switches, e.g.:

cvs update -j releasebranch_6_3 -j HEAD

This is roughly equivalent to:

cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
--
Glynn Clements <***@gclements.plus.com>
Carlos Dávila
2007-10-24 16:20:54 UTC
Permalink
Post by Glynn Clements
Post by Michael Barton
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
I followed your instructions to send some changes to both head and
release branch. Files were updated in my local releasebranch copy, but
doesn't seem to have changed in repository (or I'm looking in the wrong
place). You can check for example /display/d.extract/main.c:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.extract/?only_with_tag=
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.extract/?only_with_tag=releasebranch_6_3
Glynn Clements
2007-10-24 20:14:28 UTC
Permalink
Post by Carlos Dávila
Post by Glynn Clements
Post by Michael Barton
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
I followed your instructions to send some changes to both head and
release branch. Files were updated in my local releasebranch copy, but
doesn't seem to have changed in repository (or I'm looking in the wrong
place).
Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.
--
Glynn Clements <***@gclements.plus.com>
Carlos Dávila
2007-10-24 21:19:55 UTC
Permalink
Post by Glynn Clements
Post by Carlos Dávila
Post by Glynn Clements
Post by Michael Barton
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
I followed your instructions to send some changes to both head and
release branch. Files were updated in my local releasebranch copy, but
doesn't seem to have changed in repository (or I'm looking in the wrong
place).
Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.
Yes, but the problem is I did "cvs ci" from releasebranch copy and it
did nothing.
Glynn Clements
2007-10-25 00:16:52 UTC
Permalink
Post by Carlos Dávila
Post by Glynn Clements
Post by Carlos Dávila
Post by Glynn Clements
Post by Michael Barton
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
I followed your instructions to send some changes to both head and
release branch. Files were updated in my local releasebranch copy, but
doesn't seem to have changed in repository (or I'm looking in the wrong
place).
Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.
Yes, but the problem is I did "cvs ci" from releasebranch copy and it
did nothing.
First, check that your local copy is of the release branch, not the
trunk (or a specific release), by looking at the CVS/Tag and
CVS/Entries files for the directory in question. The former should
contain Treleasebranch_6_3, while the latter should have that tag at
the end of each entries.

Also, using "cvs update -j ... -j ..." assumes that you have already
committed the changes to the trunk. To clarify:

1. Make changes to the local copy of the trunk.
2. Commit the changes.
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
5. Commit the changes.
--
Glynn Clements <***@gclements.plus.com>
Markus Neteler
2007-10-24 11:05:05 UTC
Permalink
Post by Michael Barton
Markus,
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Michael
I have backported it for you.

Markus
Hamish
2007-10-25 03:41:15 UTC
Permalink
Some pedantic but by my experience useful steps added below,
(lessons learned as I messed things up at each one of these steps in the past)
0. 'cvs update' to be sure you are working with the latest version.
Post by Glynn Clements
1. Make changes to the local copy of the trunk.
1.5 'cvs diff' to check for left over temporary debug messages, unnecessary
whitespace changes, etc.
Post by Glynn Clements
2. Commit the changes.
2.5. Decide if the change is suitable for backporting.
Post by Glynn Clements
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
4.5 'cvs diff' check again.
Post by Glynn Clements
5. Commit the changes.
As to deciding what is suitable for backporting, I am of two minds. On one hand
it is very useful to have some sort of deadline to motivate us to fix as many
old lingering bugs as possible before the release. On the other hand even small
modifications to critical modules like g.region and r.out.gdal days before
release are very dangerous. Those need maximum testing time in the development
branch to avoid nasty unintentional side effects. It has been typical for that
sort of mistake not to be spotted even in the well tested CVS/HEAD version for
months.

A good rule seems to be only backport important bug fixes and well-tested
important updates. Leave anything else to a future release. 6.3.0 is not
intended to be as stable as 6.2, so I wouldn't worry so much about that here,
for 6.3 it becomes more a question of if the backporting justifies the double
effort.

The stable branch CVS mostly goes untested before release, so any change there
has to be very carefully done.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Carlos Dávila
2007-10-25 20:37:53 UTC
Permalink
Post by Hamish
Some pedantic but by my experience useful steps added below,
(lessons learned as I messed things up at each one of these steps in the past)
0. 'cvs update' to be sure you are working with the latest version.
Post by Glynn Clements
1. Make changes to the local copy of the trunk.
1.5 'cvs diff' to check for left over temporary debug messages, unnecessary
whitespace changes, etc.
Post by Glynn Clements
2. Commit the changes.
2.5. Decide if the change is suitable for backporting.
Post by Glynn Clements
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
4.5 'cvs diff' check again.
Post by Glynn Clements
5. Commit the changes.
Perfectly clear now, thanks both of you
Post by Hamish
As to deciding what is suitable for backporting, I am of two minds. On one hand
it is very useful to have some sort of deadline to motivate us to fix as many
old lingering bugs as possible before the release. On the other hand even small
modifications to critical modules like g.region and r.out.gdal days before
release are very dangerous. Those need maximum testing time in the development
branch to avoid nasty unintentional side effects. It has been typical for that
sort of mistake not to be spotted even in the well tested CVS/HEAD version for
months.
A good rule seems to be only backport important bug fixes and well-tested
important updates. Leave anything else to a future release. 6.3.0 is not
intended to be as stable as 6.2, so I wouldn't worry so much about that here,
for 6.3 it becomes more a question of if the backporting justifies the double
effort.
My changes only affect internationalized messages, so they neither fix
important bugs nor should create them, so the effort is the only thing
in mind.
Thanks again for the information.
Carlos

Wolf Bergenheim
2007-10-25 06:41:01 UTC
Permalink
Hi!

I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?

Ideally I'd have liked to wait for the gmath changes (since v.generalize
can be optimized after that), but I think it is more important to get
the SoC project in our next release (simply so that we can show next
year to the students that if they do good, their code ends up in the
next release).

--Wolf
Post by Markus Neteler
http://grass.itc.it/grass63/source/
-> grass-6.3.0RC1.tar.gz
An initial announcement has been drafted at
http://grass.itc.it/announces/announce_grass630.html
(state April 2007, further fixes need to be merged in)
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
Release candidate management at
http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan
Please test, test, test...
A big thanks to all contributors!
Markus
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev
--
<:3 )---- Wolf Bergenheim ----( 8:>
Paolo Cavallini
2007-10-25 06:44:19 UTC
Permalink
Post by Wolf Bergenheim
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?
+1 for me.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc
Helena Mitasova
2007-10-25 13:45:43 UTC
Permalink
Post by Wolf Bergenheim
Hi!
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?
I am very much in support of that - but has anybody besides Wolf and
me tested them?
Especially with some other data than spearfish or the new nc data set?
(e.g. latlong, very small scale etc.).

Helena
Post by Wolf Bergenheim
Ideally I'd have liked to wait for the gmath changes (since
v.generalize
can be optimized after that), but I think it is more important to get
the SoC project in our next release (simply so that we can show next
year to the students that if they do good, their code ends up in the
next release).
--Wolf
Post by Markus Neteler
http://grass.itc.it/grass63/source/
-> grass-6.3.0RC1.tar.gz
An initial announcement has been drafted at
http://grass.itc.it/announces/announce_grass630.html
(state April 2007, further fixes need to be merged in)
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
Release candidate management at
http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan
Please test, test, test...
A big thanks to all contributors!
Markus
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev
--
<:3 )---- Wolf Bergenheim ----( 8:>
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev
Maris Nartiss
2007-10-25 13:57:49 UTC
Permalink
Hi,
I used v.generalize to clean-up some data for ArcGIS users and it
worked like charm. 6.3.0 isn't a stable release - it's a
stable-unstable version :) It may bring some breakage to 6.3, but
still I would love to see v.generalize in main 6.3.0 release (even if
it means to wait another week before final version is out).

WBR,
Maris.
Post by Helena Mitasova
Post by Wolf Bergenheim
Hi!
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?
I am very much in support of that - but has anybody besides Wolf and
me tested them?
Especially with some other data than spearfish or the new nc data set?
(e.g. latlong, very small scale etc.).
Helena
Continue reading on narkive:
Loading...