[Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

Nick Coghlan ncoghlan at gmail.com
Fri May 29 13:39:55 CEST 2015

On 29 May 2015 20:24, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Nathaniel Smith writes:
>  > DVCS back in the day :-). Unfortunately hg makes this a little
>  > trickier than it could be, because in hg the same commit can't be in
>  > two different branches; but this just means you have to insert some
>  > no-op merges, oh well.
> Don't use named branches ("friends don't let friends ...").  Use
> bookmarks.  Theoretically that should work fine.

The key is whether or not we can readily notify people when the "most
recent known good" hash *changes*, and less about the mechanics of how we
then record the history of which commits *were* stable, or the identity of
the most recent commit.

That said, prompted by Nathaniel's comment, I realised that having a
"post-BuildBot" stable repo is one possible way we could achieve that. That
way we could introduce merge gating without needing to change anything at
all about how we manage the current development repo, we'd just push stable
versions to a separate repo that only the BuildBot master (or a dedicated
service monitoring for successful cross-platform BuildBot runs) and the
release managers had permissions to push to.

The commit hooks on that *stable* repo could then be used to trigger third
party test suites only for builds that at least passed CPython's own test

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150529/9e7c0d68/attachment.html>

More information about the Python-Dev mailing list