Transitioning to the new Release Process

[Johannes Pfau]

Am Fri, 11 Jan 2013 18:54:12 +0100
schrieb "mist" <none at none.none>:

> Short comment about cherry pick - it is only bad in sense that it
> creates separate untrackable commit with same content, which may
> easily result in merging issues. If there is only one-way
> direction for commit transitioning ( stuff goes from master to
> staging and LTS and never goes back ) there is nothing inherently
> bad about cherry pick.

Having multiple commit ids for the same commit is also annoying. For
example if someone bisected a regression and you want to revert a commit
you have to figure out the commit id of the cherry picked commits.

> 
> On topic: well, it was somewhat discussed in the very first
> thread. One pure technical issue is that github choses master as
> default target for pull requests and people gonna do it wrong by
> a simple mistake rather often.
It doesn't harm though if a requests goes to master instead of staging
- the only difference with the approach described on the wiki page is
that the bug fix will be delayed by one release if it's merge into
master instead of staging.

> Much more important point is that
> it complicates development process for newcomers without any
> reasonable benefit. And if we still gonna push for success as an
> open-source project, being easy understandable by an outsider is
> as important as a clear release process.
The rule is quite simple and easy to understand though:
regression fix -> version branch
bug fix -> staging
enhancement -> master

The benefits have already been stated in other posts.
> 
> Come on, I am reading all new posts in D and D.announce almost
> every day (for 2+ years), check most of github pull requests for
> druntime and phobos on weekly basis and still have a hard day
> figuring out how some stuff is supposed to be done regarding
> process and intentions. Imagine some random guy who just fixed
> some stuff for his project and now he is full of altruistic
> intentions to provide this fix/feature to an upstream. We have
> current scenario A - fork repo on github, do stuff, push "pull
> request" button. And now scenario B is proposed - go to wiki,
> read release process guidelines, chose branch to fork from, do
> not forget to chose the same branch when doing pull request
> shortly after. Minor details regarding people comfort matter a
> lot when they are supposed to work for free.

It's always possible for a maintainer to get the changes from the pull
request into their personal repo, rebase on the correct branch, reopen.
And it's not that bad if a request goes to master accidentally.

Regression fixes have to go to version branches anyway, you can't avoid
this without cherry-picking. But newbies don't do regression fixes
anyway.

Separating between staging and master then has the nice benefit of a
more stable "beta" branch and a fast moving development branch.