[GRASS5] proj changes for releasebranch?

[Glynn Clements]

Markus Neteler wrote:

> > The currently called 5.1 could become 5.9.x (to end in 6.0 then)
> > and the datum transformation (as well as the polished NVIZ?) go into
> > 5.2.0 after a short period of 5.1.x.
> >  
> > > There are known actual bugs in 5.0.2; it would have been nice to have
> > > a 5.0.3 version which fixes the bugs in 5.0.2 with absolutely zero
> > > chance of breaking anything else in the process.
> > I agree.
> 
> Well, thinking again about it:
> 
> Apart from the (theoretical) desired versioning, we have some
> practical implications:
> 
> - who would maintain the 5.0.x release branch

I could do that, if 5.0.x were just bugfixes.

My comments about not being able to handle both 5.0 and 5.1 was based
upon the current "5.1" being a radical departure. It wouldn't apply to
a version which was just "upgrades" to 5.0 like the datum stuff and
NVIZ changes.

> - who would create and maintain a new 5.1.x/5.2.x release branch

Creating a branch is simple enough. It would be maintained by the
developers who are currently choosing to make significant changes to
5.0.x rather than migrating to the "grass51" tree (which seems to be
everyone except Radim).

> - most important: will the developers ever move to the (current) 5.1/5.9/6.0
>   when a new 5.1.x/5.2.x release branch would be opened?

I don't know. But the issue of migrating developers to grass51 is
separate to how to handle non-trivial (i.e. non-bug-fix) changes to
5.0.x.

In that sense, there isn't any difference between allowing non-bug-fix
changes to 5.0.x and creating a 5.1.x branch; the difference is
whether end users (most of whom aren't going to be moving to grass51
soon) can get the bug fixes without potentially destabilising
upgrades.

Consequently, I suggest restricting 5.0.x to bug fixes, and either:

a) creating a 5.1.x branch for upgrades, and renaming "grass51" to
e.g. "grass6", or

b) decree that anyone wishing to do more than just fix bugs must
migrate to grass51/grass6.

Option a) means that grass51 will remain non-mainstream for longer;
option b) risks alienating developers. Actually, option a) also risks
alienating developers if the two trees ("grass" and "grass51") diverge
and one lot of effort ends up being discarded.

BTW, allowing non-bug-fix changes to 5.0.x has the same effect as
option a) in terms of dividing the development effort. Basically,
either you push developers into working on grass51, or you don't.

-- 
Glynn Clements <glynn.clements at virgin.net>