[GRASS-dev] too many branches

[Markus Metz]

On Wed, Aug 22, 2012 at 7:28 PM, Michael Barton <michael.barton at asu.edu> wrote:
> The way I thought I understood the plan is that we would have an odd
> numbered version for development, testing, etc and an even numbered release
> version. So it has seemed to me that 6.4.3 is the place where we were
> supposed to be testing any enhancements and bug fixes before doing an even
> numbered 'stable' release. So I too have remained confused about why we
> needed a testing/development version 6.5 that fed into a testing/development
> version 6.4.3, that fed into a final stable release (6.4 on the way). But
> maybe I misunderstand this workflow and someone can explain it to me.

I think we need to need to achieve some agreement about what is
allowed to get changed in 6.4.x. I thought that only bug fixes and
popular enhancements should go into 6.4.x. I thought that a
development branch 6.5 should be used for new features which do not
qualify for 6.4.x. I thought that bug fixes should immediately go into
all branches and not implemented in one branch, then forgotten. I
thought that testing of a bug fix takes place in the svn version of
6.4.x. If the bugs are confirmed fixed, a new 6.4.x can be released.
But this is what I thought initially. By now I learned that quite a
lot is possible in 6.4.x, even the API can change and script
compatibility can be broken (IMHO excusable because new features were
implemented too quickly without proper testing, the problem was the
inclusion of new, not well tested modules).

What has happened in the last years is that bugs where more or less
randomly fixed in 1, 2, or 3 branches, if in only one branch, it could
have been any of the 3. 6.5 was just used to backport new features
which have first been implemented in 7.0, and which then went into
6.4.x. In the worst case, bugs were fixed in a branch that was meant
for new features, but not in the releasebranch, and then forgotten.
IMHO this is a mess.

>
> But that can be all moot now that we are moving towards a 6.4.4 release.
>
> Why don't we:
>
> 1) freeze (really freeze this time) 6.x for new features after the 6.4.4
> release
> 2) keep 6.5 for bug fixes (bug fixes only, no enhancements, no backports of
> new features) to the 6.x line
> 3) start a 7.0 release branch and a 7.1 dev branch so that we can begin to
> move toward a GRASS 7 release
>
> How does this sound???

I agree, but would like to see a feature freeze after 6.4.3. New
features should go into the next larger minor version (I thought).

About 6.5, it can not really be used as technology preview, because 7
is too different. The wxGUI might be an argument for 6.5 though.

Markus M

PS: As a user I can not use 6.x for production work because GRASS 6 is
not able to perform the kind of analyses I have to do for my job. I
have to use GRASS 7.

>
>
>
> On Aug 22, 2012, at 6:32 AM, <grass-dev-request at lists.osgeo.org>
>  wrote:
>
> From: Markus Neteler <neteler at osgeo.org>
> Date: August 22, 2012 6:18:32 AM MST
> To: GRASS developers list <grass-dev at lists.osgeo.org>
> Subject: Re: [GRASS-dev] too many branches
>
>
> On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa <landa.martin at gmail.com>
> wrote:
>
> 2012/8/22 Hamish <hamish_b at yahoo.com>:
>
> Is there any comparison of devbr6 a relbr64?
>
>
> Yes:
> diff -ru --exclude=".svn" grass64_release grass65_release
>
> To even exclude the timestamp differences in the HTML pages:
> diff -ru --exclude=".svn" --exclude=".html" grass64_release
> grass65_release  | wc -l
> 856878
>
> Not really the same :)
>
> I am pretty sure
>
> that many changes, fixes which has been committed to devbr6
>
> were not applied later in relbr64.
>
>
> very serious question: does it matter? if it is a serious bug
>
>
> Yes: most tickets I have indicated earlier which contain a backport
> promise are relevant.
>
> I have gone before every GRASS 6 release through this branch
> differences. It took me every time days. And I start to not have
> that time any more to catch up with incomplete tickets... (see above).
>
> And yes, energy should go of course into GRASS 7.
>
> MarkusN
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev