>As decided earlier, 4.0 will a series of unstable releases. Once Gtk3 and python3 support of the plugins is up to point, we would have a 4.1.0 stable release.
>I hope to do Unstable 4.0.0 Alpha release before Christmas.
>My question: how to handle subversion branches the most easy?
>As 4.0 will be unstable releases, my preference goes out to not doing a gramps40 branch, and just tag the unstable releases from trunk. Then, when we prepare for 4.1, we create 4.1 branch and trunk becomes open for large new features.
>You agree with this?
It's fine with me. But.... It seems a little bit rude to forbid other developers from working on new features. You will basically force others to create task branches for their feature work and they will have to merge your changes into their branch from trunk. Then, when 4.1 is finally created they have to merge their new features into trunk.
Does anyone have any aspirations to work on new features? I know there was talk of reworking the narrative web report. If nobody has any new feature plans, then let's do what Benny suggests. But if we have new feature work in mind for the short term, then let's consider making a 4.0 maintenance branch right away.
Also, I have some slight reservations about the release numbering. If we release something called "4.0.0.alpha1", I think we will be fine. But I am concerned about releasing something called "4.0.0" - even if we make a note in the release notes that it is "unstable", some packagers or users might pick it up unwittingly. How would you feel about making all unstable releases have some kind of suffix like "alpha1", "alpha2", "beta1", "beta2", etc? Then, you could make the first "stable" release "4.0.0" proper.
Another idea would be to allow new feature work in trunk but still make unstable releases - but just ask people to be careful not to break trunk too badly. Then, when the GTK/Python work is all caught up, we create a maintenance branch and stabilize the new features.
I'm just thinking out loud here. I think any scenario will work.