On sábado, 8 de dezembro de 2012 09.53.44, Alan Alpert wrote: > This thing about the non-destabilizing bug fixes is just the release > team being cautious because we don't have a release branch yet. > Theoretically I'd have thought the release branch should have started > for RC1 and then the release team would cherry-pick fixes into that > branch. But if that's not happening then we just have the same work > flow as in 4.x when there was only one master: be cautious with > commits around release time. The only reason this might be perceived > as a regression is that we actually have another branch that won't get > into the release, allowing development to continue like we had always > dreamed of. > > So it seems we're currently only half-way over into our new branching > paradigm and that will be confusing until we shift fully. Unless I got > the new paradigm wrong, in which case it's confusing now .
No, you didn't. I discussed this with Lars and Tuukka yesterday before leaving for the airport. We discussed whether we should branch now at RC1, wait until RC2 or even longer. There are good arguments in both directions: - if we don't branch now, we risk destabilising changes going in, changes that should be kept back. - what's more, if we don't branch now, there's nowhere to put important bug fixes that just need a little more testing (i.e., the ones for 5.0.1) - however, if we do branch now, we create work for the release team for cherry-picking the important fixes or redirecting to the release branch. So we discussed a judgement call: to us, it looked like we'll need a lot of necessary fixes on top of RC1 -- some of which we already know, which is why we're certain there will be an RC2. If we branch now, we create a lot of additional work. The risk of a regressing change being accepted is worth the gain in workflow. We'll create the releases branch for the RC2 then. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
