[GRASS5] GRASS stable/exp branches

[Radim Blazek]

> My vote is to not add any more features to 5.0 at all. Any 5.0.x release
> in my opinion should only contain bug fixes which we may have missed for
> 5.0.0. Any new features will go into 5.1.
>
> > We need to get 5.1 up then as fast as possible.

I agree. 

> Yes, and to me, the easiest way to do that is to mark the current tree
> stable and comment out those modules considered unstable from the
> src/CMD/lists/GRASS file. We can decide stability on a module-by-module
> basis when we create the new directory structure for 5.1.

Yes, I think it's better than tagging individual modules in repository.

> Not necessarily. There are two ways to approach this. We can assume that
> we do not trust any module to be stable and Markus will have to check
> each one himself. Or, we can assume that most modules are stable and
> find the unstable ones through bug reports during pre-testing and post
> release time. This way, each module does not have to be checked and we
> get 5.0 released sooner. The only downside is that we may release a few
> unstable modules, but I don't think we will have anything serious fail.
> Please remember that this would only be for the 5.0 release. I think
> each module does need to be checked, but I would say the best time to do
> that is when we are placing the modules in the new directory structure,
> since we won't have the pressure to release something at that time.
> Ultimately, it will be Markus who decides what he will do. :-)

I vote for second option.

> 1. Define bugs to be fixed for 5.0 and urge developers to claim them on
> RT. After a short period of time, those bugs not claimed are left for
> 5.1. Unclaimed bugs won't be fixed and a decision made to mark them as
> unstable or not.
>
> 2. Create a stable branch (maybe do this at the same time as 1?). Only
> *minor* bug fixes are allowed to be committed to the stable branch along
> with those identified in 1. Major bug fixes can be committed only after
> developer consensus or approval from Markus. Requirement for a major bug
> fix to be committed is that it fixes something crucial to the operation
> of Grass. No new features are allowed to be committed to the stable
> branch.

I am probably missing something but if we say that only bugfixes will go into
grass5.0.x and grass51 is already established in NEW repository 
(RESTRUCTURED:  http://freegis.org/cgi-bin/viewcvs.cgi/grass51/  ),
I don't see why we need branches (at this moment and in at least next year)