Glynn Clements wrote:
> Ideally the 6.3-release branch would be a branch from 6.x-devel, as
> that's how it's structured in CVS. But that may not be possible
> given that it existed prior to the migration to SVN.
Markus:
I wonder if we should sort of re-do the 6.3-release branch. I am not
aware of incompatible changes within HEAD yet. Maybe it is better
to branch off again (say, to bulk merge from HEAD/trunk into the
existing branch) to catch recent fixes for 6.3.0.
we have already gone to the trouble of having the RCs, so why not just tag
6.3.0 *now* from releasebranch_6_3, close that branch and tag a 6.3.1
from from the 6.x devel branch (be that trunk/ or its own branch by then)
sometime after all the migration dust settles? (early february?) As long
as we clearly note it is a beta release which is expected to contain
problems...
Glynn Clements wrote:
> The general principle is that no development occurs on a release
> branch.The general scope should be to fade out 6.x *development* (keep
maintenance) and focus on GRASS 7. Given our limited resources, I don't
see an alternative. We all would like to make so many major changes to
GRASS that this cannot happen in the 6.x line but in 7.x only. So let's
start!
go go go!
but first... have we settled on a branch plan?
my 2c version (where "my" = assimilating the ideas of others):
order of action something like:
[now, or in the next weeks as holiday time allows]
1. tag 6.3.0, ship it, forget it
-6.3.1 from releasebranch_6_3 only if 6.3.0 is a brown paper bag
(the goal is a stable 6.4, not maintaining a stable 6.3.x)
2. create 6.x limited-devel branch
-6.3.1 from that (b or t?), leading to a releasebranch_6_4 from
which 6.4.0RCx and 6.4.x releases will be cut.
create releasebranch_6_4 the same day as 6.4.0rc1 is tagged.
3. label trunk/include/VERSION as 7-dev code
[time passes]
? 4. backports to & releases of 6.2.x, 5.4.x, 6.4svn as needed *FROM 7*.
I am still unsure how we fill the usability void that "make mix" looked
after for grass 5.1/5.7, while 7.x is undergoing major changes and not
suitable for day to day "production" use.
-- related: what's the best way to backport to branches in SVN?
(replacement for 'cvs up -j HEAD ...')
suggestions,
Hamish