[yt-dev] Proposed modification to YTEP-1776: bugfixes to the stable branch, code freezes

[Nathan Goldbaum]

Hi all,

Before making a PR to the YTEP repository, I wanted to propose a
modification to our development workflow to the mailing list.

In particular, I think we need to be more careful about what changes go to
the yt branch and the stable branch.

Right now we suggest all new changes, including bug fixes, API changes, and
new features, go to the "yt" branch.  Periodically, we merge from the "yt"
branch into the "stable" branch, tag the merge with a release number, and
upload to pypi.

This means that we are restricted in making bugfix releases that include no
breaking changes.  As soon as a new feature gets merged into the "yt"
branch, by all rights the next merge-to-stable and release should be a
minor version change instead of a patch version change (i.e. we should be
releasing yt 3.1 instead of yt 3.0.1 after merging in a new feature or API
change, see http://semver.org/ for more details on this nomenclature).
Generally, people expect patch version bumps to only include bugfixes.

I'd like to propose a modification to our development workflow that should
make it easier to make sure bugfixes can be released without breaking
unrelated things, while still allowing us to temporarily break stuff on the
dev branch.

I think rather than merging from the "yt" branch into "stable" *every* time
we do a release, we should instead issue patch releases from the current
state of the stable branch.  Instead of merging from "yt" into "stable"
with every release, we should only do so before a minor or major version
release, not patch releases.

This means that bugfixes will need to go to the "stable" branch instead of
the "yt" branch.  It also means that the "stable" branch will need to be
merged into the "yt" branch with some regularity to make sure bugfixes make
their way to the dev version of the code.  It will also take some degree of
manual care to ensure that the "@" bookmark always points at the tip of the
stable branch so fresh clones get bugfixes.  Additionally, bugfixes may
need to be backported or cherrypicked from the "yt" branch to the "stable"
branch if a bugfix comes in as part of some bigger change or if a
contributor isn't aware that bugfixes should go to the stable branch.

This workflow sort of matches what's done in the mercurial community.

I think it would be a good idea to follow the mercurial community in
another way, we should institute a "code freeze" for the two weeks prior to
a non-bugfix release. This means that all developers switch to the tip of
the "yt" branch, and only PRs that fix bugs, documentation issues, or
improve error messages can be merged. Just before release, the "yt" branch
is merged into "stable".

See http://mercurial.selenic.com/wiki/TimeBasedReleasePlan for more
details.

Instituting such a testing period should help us understand the scope of a
release a few weeks out, keep pre-release documentation updates bounded,
and hopefully help suss out bugs since most developers will be testing a
sync'd up-to-date version of the code that people will actually be using.

What do you all think about these proposals?  If there's broad agreement
that this is a good idea, I'll put this proposal together as a patch for
YTEP-1776.  If not I'll hold off for a while until we can come to a
consensus.

Best,

Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20141103/f2cd438b/attachment.htm>