On Wed, Aug 22, 2012 at 7:28 PM, Michael Barton <michael.bar...@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-requ...@lists.osgeo.org> > wrote: > > From: Markus Neteler <nete...@osgeo.org> > Date: August 22, 2012 6:18:32 AM MST > To: GRASS developers list <grass-dev@lists.osgeo.org> > Subject: Re: [GRASS-dev] too many branches > > > On Wed, Aug 22, 2012 at 3:07 PM, Martin Landa <landa.mar...@gmail.com> > wrote: > > 2012/8/22 Hamish <hamis...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev