On 23/06/14 17:35, Martin Landa wrote:
Hi,
2014-06-23 10:56 GMT+02:00 Moritz Lennert <mlenn...@club.worldonline.be>:
... so, getting out 7.0 seems to be endless...
A radical solution might be to change trunk into GRASS GIS 8. Then we
do not need to wait in 7 for API stabilization and can release it "as
is" and go ahead with the planned massive improvements.
I think that there is no need for GRASS 8 at this moment, it's not
related to GRASS 7 release management. The real problem is that we
don't have clear list of desired features for GRASS 7. Once we start
with RC stage we need to be sure that we are close to the final
release - to avoid RC for months or even several months like happen in
the past. We should also vote about RFC4 before we start with RC
stage. Personally I would start with GRASS 8 when there will be a
clear reason for that.
This sound ok to me. So, ideally, at all times we should have one release
branch and one development branch. Releases can then just be tagged from the
release branch which gets only selected, well-tested, not to invasive
backports from the dev branch.
That is also reason why I would keep trunk as 7.1 before we start with
tagging 7.0.0RC1.
Once we decide that the dev branch is sufficiently different from release
that backports become unfeasible, and sufficiently stabilised that we can
branch a release branch out of it, we declare the previous release branch a
legacy maintenance branch (with only limited bug fixing from that point on),
and branch a new release branch.
I would prefer to create just release branches. E.g.
* We start with tagging 7.0.0RC1.
* We create releasebranch_7_1 from trunk
* Trunk becomes 7.2 or GRASS 8
>
* We continue with backports only in releasebranch_7_0 towards final release
* Development will continue in trunk and releasebranch_7_1
* After some period we freeze releasebranch_7_1 and create
releasebrach_7_2 from trunk/releasebranch_7_1.
* We start RC stage in releasebranch_7_1
* Development will continue in trunk a releasebranch_7_2.
Ok, so you prefer a solution with three branches (besides the legacy
maintenance branches), in this case
- releasebranchX.Y
- releasebranchX.Y+1
- trunk
?
This does have the advantage to allow experiments to happen in trunk.
But it has the disadvantage of having to manage backporting between
these branches.
My proposal would be just two branches:
- releasebranchX.Y
- trunk
The release branch would only live throughout the time of a specific
release and then become legacy maintenance.
The question is how to introduce highly experimental stuff. We can open
a windows between release branches to introduce new stuff in trunk. At
one point (something like a month before the creation of a release
branch) we stop any experimentation in trunk and iron out what needs
ironing out before creating a release branch out of trunk...
This risk of that approach is that some feature will not be tested as
long before release as in your proposal, but it has the advantage that
everyone just works in trunk, with release branches just created at the
time of releases. If I'm not mistaken this is more of less how QGIS
development works, or ?
One option would be to have people experiment more in their personal
trees and commit innovative features to trunk only when in late beta
stage. This would probably mean switching to git or something like that
since it seems more adapted to this style of development than subversion.
Moritz
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc
