[Pharo-dev] About contribution process, people participation and communication (WAS: Re: [ANN] Pharo 8.0 development started)

Ben Coman btc at openinworld.com
Sun Dec 30 12:04:29 EST 2018

On Sun, 30 Dec 2018 at 23:28, Esteban Lorenzano via Pharo-dev <
pharo-dev at lists.pharo.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20181231/2095982a/attachment.html>

More information about the Pharo-dev mailing list