planning for v2

[Rob McBroom]

There are several pull requests where I wanted to bring this up, but I don’t want the discussion scattered, so let’s do it here.

Now that 1.2.0 is out, I was thinking of creating a v2 branch. On that branch…

• I was planning to merge some of Etienne’s 97% finished pull requests and finish them (#1601, #1611)
• Merge #1803
• Re-instate the auto-layout based results window
• Any pull requests that address 2.0.0 issues should be made against that branch

That will lead to some questions:

If fixes are made for a 1.2.x release, do we leave those on master and not on v2? I’d like to have v2 always up to date with master. It would allow us to catch conflicts earlier when they’re easier to deal with. But that would require rebasing and force-pushing v2 all the time. We’ve done this in the past with release and it’s kind of a mess and just feels wrong.

What’s really pressing that needs to go into 1.2.x?

Does anyone have a better strategy for starting on the big 2.0.0 stuff, while still leaving a place to do hot-fixes on 1.2.x?

--
Rob McBroom
http://www.skurfer.com/

[Patrick Robertson]

I agree we need another branch. Or, perhaps we should branch off a ‘v1.2.x’ branch instead, and keep development work on master.

I like what Django do: [1], [2], [3]

Basically, they branch off from master when a release is made, then that branch is kept about for any bug fixes/security updates. Those fixes are merged into master (development branch) as well.

Looking at Django’s commit SHAs across branches for bug fix commits [4] and [5] you’ll see that the branches aren’t rebased on each other. They say in the commit message that they’re a ‘backport of #####’.

My guess is they add any bug fixes to master, if it’s also present in previous releases they just do a merge of the pull request into those - no need for a rebase or merge. (If we know that the PR we’re making is for a bug fix to 1.2.x, we put that in the start of the PR/commit with "[1.2.x]”. (See [2] for how Django do it)

FYI I thought the whole point of rebases is so that you *don’t* have to do a force push. If the rebase isn’t clean, then you should do a ‘merge’ and fix any conflicts in the merge commit. [3] has some detail on this if you scroll down a bit: “After upstream has changed”

I think whatever solution we take, we’ll probably need to work a lot more on unit tests. I.e. if we find a bug - write a unit test as part of the PR. We can then check the bug on the v1.2.x branch - if it fails there we know to backport the commit.

As for what needs to go into 1.2.x - most of the issues from the last week or so probably need to be included.

[1] https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions

[2] https://docs.djangoproject.com/en/dev/internals/contributing/committing-code/#committing-guidelines

[3] https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/working-with-git/#rebasing-branches

[4] https://github.com/django/django/commit/314e9cd38f6bf72a619e5d07c99371439c33ba11

[5] https://github.com/django/django/commit/f58392d8d8b68e2e7777768f39941cd995ce16e4

--
You received this message because you are subscribed to the Google Groups "Quicksilver - Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quicksilver---deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.