Le 07/03/2017 à 01:06, Scott Kostyshak a écrit :
When we branch 2.3, this branch would be named "2.3.x", right? The slightly weird thing would be that the release manager would be in charge of the 2.3.x branch until 2.3.0 and then the stable branch maintainer would be in charge of the branch after 2.3.0.
As you say, it is only slightly weird, and the easiest is probably to get over it :)
For the sake of argument, what would be the disadvantage to branching even before the feature freeze?
I would say that backporting features is more work than backporting fixes...
This discussion gets more complex once we talk about our opinions regarding 2.3.1 and 2.3.2 releases. When we get close to releasing 2.3.0, there will be bug fixes that might be viewed as desirable for eventual inclusion in 2.3.x, but too risky for 2.3.0.
We might want to put some pressure here by setting dates and trying to stick to them. We have to accept to drop some things from a release and keep them for the next, especially if these releases come somewhat quicker (we can always dream!). It _might_ happen that our shiny CI infrastructure will actually help in this regard.
Actually, now that I think about it, it seems that we could reduce the number of branches by one by not having 2.3.1-staging. I wonder if the following would be a clean way of proceeding: [...]
I do not have strong feelings here. We shall do whatever the maintainer is more comfortable with. Use the simplest scheme that serves us well.
JMarc
