On Sun, 30 Dec 2018 at 23:28, Esteban Lorenzano via Pharo-dev < [email protected]> wrote:
> > Now, while the general direction was explained, I think I failed to > communicate several things. > For what I can think at this moment (for sure there are a lot more): > > - I failed to communicate that opening Pharo 8.0 branch didn’t mean > closing Pharo 7.0 development, just to allow people doing big changes to > merge them. > - I failed to communicate correctly that having a release candidate (rc1) > meant “code freeze” (and then forbidding new changes except bug fixing). > Thanks for acknowledging this Esteban. In spite of the communication issue, the point I'd make in support of this arrangement is that historically we've done poorly with code-freezes, or even the lesser strength feature-freezes leading up to a release. A code freeze can be discouraging when integration of new features are delayed and can weaken such the code freeze. Opening the next-version-dev branch when the current-version freezes for release-candidate seems to facilitate pre-release stability - though the risk though of mind-share drifting to the next-version-dev branch needs to be managed. cheers -ben
