master vs maintenance branches (current process and proposal for future workflow)

Hey everyone,

So I don’t have a clear picture in my head of our development cycle, and I don’t think it’s well documented. I didn’t want thread jack, but in another thread Mike wrote:

(BTW – feel free to submit pull requests at any point in a release

cycle – we have both a master and a maintenance branch, so we can work

on new stuff and stable stuff at the same time).

My first question is, how are these two branches related, because I’ve been submitting things against master, and then switching it to be against 1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes, and master is for new features.

Can someone clarify the current process, with a section like “Submitting new Pull Requests” - this should probably go into one of these places:

http://matplotlib.org/devel/coding_guide.html

http://matplotlib.org/devel/gitwash/index.html

My second question is that, if I do have the right idea about the current process, and the distinction between master and 1.2.x, should we change this? (I think we should).

The trouble is that it seems to me now for a bugfix, if it is submitted against 1.2.x, it won’t be fixed in master until changes from 1.2.x are merged back into master. So now as a developer trying to follow “bleeding edge” matplotlib, I either have to live with bugs that have been fixed in 1.2.x if I want the features from master, or if I want the bug fixes and follow 1.2.x, I miss the new features in master.

I think that the mental picture is sufficiently clearer if everything (bugfixes and new features) go into master, and then we backport the critical bugfixes against 1.2.x. This would be easier to do if the core developer merging the bugfix into master at least opens an issue for as a placeholder / reminder for the bugfix being a candidate to go into the maintenance branch. Because it seems like at this point, we aren’t even sure if we’re going to do a 1.2.1 release…

better,

···

On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <mdroe@…31…> wrote:


Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Hey everyone,

So I don’t have a clear picture in my head of our development cycle, and I don’t think it’s well documented. I didn’t want thread jack, but in another thread Mike wrote:

(BTW – feel free to submit pull requests at any point in a release

cycle – we have both a master and a maintenance branch, so we can work

on new stuff and stable stuff at the same time).

My first question is, how are these two branches related, because I’ve been submitting things against master, and then switching it to be against 1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes, and master is for new features.

That is correct.

Can someone clarify the current process, with a section like “Submitting new Pull Requests” - this should probably go into one of these places:

http://matplotlib.org/devel/coding_guide.html

http://matplotlib.org/devel/gitwash/index.html

This is the essence of the gitwash process. Perhaps it needs to be clearer.

My second question is that, if I do have the right idea about the current process, and the distinction between master and 1.2.x, should we change this? (I think we should).

The trouble is that it seems to me now for a bugfix, if it is submitted against 1.2.x, it won’t be fixed in master until changes from 1.2.x are merged back into master. So now as a developer trying to follow “bleeding edge” matplotlib, I either have to live with bugs that have been fixed in 1.2.x if I want the features from master, or if I want the bug fixes and follow 1.2.x, I miss the new features in master.

A general rule is that whoever merges a bugfix to the maintenance branch should then also manually merge the maintenance branch down to master.

I think that the mental picture is sufficiently clearer if everything (bugfixes and new features) go into master, and then we backport the critical bugfixes against 1.2.x. This would be easier to do if the core developer merging the bugfix into master at least opens an issue for as a placeholder / reminder for the bugfix being a candidate to go into the maintenance branch. Because it seems like at this point, we aren’t even sure if we’re going to do a 1.2.1 release…

There are other git workflows, which are all perfectly valid. If you can convince us to use another, feel free to propose one. However, we have done a couple of releases with gitwash, and it has worked quite well for us given how small our maintenance overhead is. Just have to remember to regularly merge the maintenance branch to master. That’s all.

Cheers!
Ben Root

···

On Mon, Nov 12, 2012 at 3:44 PM, Paul Ivanov <pivanov314@…149…> wrote:

On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <mdroe@…31…> wrote:

Personally, I use this one:
http://nvie.com/posts/a-successful-git-branching-model/

It does involve a little more effort, it does also mean that someone
installing from the master branch (which is the default branch) will
always get a stable release. My feeling is that the master branch
shouldn't contain any unstable code. Also, it means that the user can
just clone the git repository without having floating tarballs all
over their home directory.

I'm not necessarily proposing we should change it, I just wanted to
point out a different approach. The git branching workflow we use for
matplotlib is perfectly valid and I'm happy using it.

···

On Mon, Nov 12, 2012 at 2:52 PM, Benjamin Root <ben.root@...553...> wrote:

On Mon, Nov 12, 2012 at 3:44 PM, Paul Ivanov <pivanov314@...149...> wrote:

Hey everyone,

So I don't have a clear picture in my head of our development cycle, and I
don't think it's well documented. I didn't want thread jack, but in another
thread Mike wrote:

On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <mdroe@...31...> >> wrote:
> (BTW -- feel free to submit pull requests at any point in a release
> cycle -- we have both a master and a maintenance branch, so we can work
> on new stuff and stable stuff at the same time).

My first question is, how are these two branches related, because I've
been submitting things against master, and then switching it to be against
1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes,
and master is for new features.

That is correct.

Can someone clarify the current process, with a section like "Submitting
new Pull Requests" - this should probably go into one of these places:
http://matplotlib.org/devel/coding_guide.html
http://matplotlib.org/devel/gitwash/index.html

This is the essence of the gitwash process. Perhaps it needs to be clearer.

My second question is that, if I do have the right idea about the current
process, and the distinction between master and 1.2.x, should we change
this? (I think we should).

The trouble is that it seems to me now for a bugfix, if it is submitted
against 1.2.x, it won't be fixed in master until changes from 1.2.x are
merged back into master. So now as a developer trying to follow "bleeding
edge" matplotlib, I either have to live with bugs that have been fixed in
1.2.x if I want the features from master, or if I want the bug fixes and
follow 1.2.x, I miss the new features in master.

A general rule is that whoever merges a bugfix to the maintenance branch
should then also manually merge the maintenance branch down to master.

I think that the mental picture is sufficiently clearer if *everything*
(bugfixes and new features) go into master, and then we backport the
critical bugfixes against 1.2.x. This would be easier to do if the core
developer merging the bugfix into master at least opens an issue for as a
placeholder / reminder for the bugfix being a candidate to go into the
maintenance branch. Because it seems like at this point, we aren't even sure
if we're going to do a 1.2.1 release...

There are other git workflows, which are all perfectly valid. If you can
convince us to use another, feel free to propose one. However, we have done
a couple of releases with gitwash, and it has worked quite well for us given
how small our maintenance overhead is. Just have to remember to regularly
merge the maintenance branch to master. That's all.

--
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

For what it's worth, what Paul describes is essentially the process we use
in IPython. All pull requests target master, and critical fixes are
backported if we decide we're going to do another maintenance release. This
is easier for contributors, because all pull requests work the same way,
but I think it does take some time for someone to go through the issues
tagged for backporting and cherry-pick the commits. Min tackled that for
our recent maintenance releases.

We use pull request testing to keep master reasonably stable, although we
don't make any promises about it.

Best wishes,
Thomas

···

On 12 November 2012 20:52, Benjamin Root <ben.root@...553...> wrote:

There are other git workflows, which are all perfectly valid. If you can
convince us to use another, feel free to propose one. However, we have
done a couple of releases with gitwash, and it has worked quite well for us
given how small our maintenance overhead is. Just have to remember to
regularly merge the maintenance branch to master. That's all.