[GRASS-dev] GRASS 6.3.0RC1 released

Hamish hamish_nospam at yahoo.com
Wed Oct 24 23:41:15 EDT 2007

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)

Glynn wrote:
> To clarify:

0. 'cvs update' to be sure you are working with the latest version.

> 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.

> 2. Commit the changes.

2.5. Decide if the change is suitable for backporting.

> 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.

> 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

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

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


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the grass-dev mailing list