GRASS 7 planning: trunk and branches management

General plan

• GRASS 6.3.0 will be released from the releasebranch_6_3 branch
• a new releasebranch_6_4 branch will be created, essentially doing bugfixes
• trunk becomes GRASS 7.0.svn, it will be drastically restructured

GRASS 6.2 releases

• Release scope: maintenance mode (no native winGRASS support, no wxgrass)
• An update to 6.2.3 is not planned unless a really nasty bug is found.

GRASS 6.3 releases

(draft)

• Release scope: technology preview (with native winGRASS support, no wxgrass)
• fix ​open bugs if there is interest
• Once released, an update to 6.3.0 is not planned unless a nasty bug is found.

: Should we backport general bugs anyway (just in case) or is that wasted effort?

--HB: I feel porting fixes between 4 active branches is too much. (6.2svn, 6.4svn, and 7svn)

• Once the wxPython GUI is ready for formal beta testing, we might consider doing another 6.3.x including that.

: That will need to be taken from the 6.4 release branch. As is it hard (or is it?) to backport all new changes to the 6_3 release branch in bulk, maybe it is better to call 6.3.1+wx as 6.4.0pre1 and keep in in the 6_4 branch instead of attempting an ugly merge of everything back to 6_3?

GRASS 6.4 releases

• Release scope: new stable release (with native winGRASS support, with wxgrass)
• fix ​open GForge bugs
• fix ​open trac bugs
• test and apply ​available patches
• new documentation and translation efforts will happen in the 6.4 branch
• wxgrass development will continue for now in the releasebranch_6_4 branch

GRASS 7 Ideas collection

(to be moved here)

• Release scope: complete demolition and reconstruction (new display architecture, new raster library, new ...)
• ​http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection