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