[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