V1.3.5 branch

[0x1mason]

No description provided.

[jlipps]

I don't understand---was 1.3.5 on its own branch this whole time?

[paymand]

Yep. Not cool 👎

[bootstraponline]

😭

[0x1mason]

It was only on its own branch once the beta was released. That's what we
agreed to do and did for the previous few releases. I'm not sure what the
problem is. There isn't really another way to do it.

On Fri, Feb 20, 2015 at 6:13 PM, bootstraponline notifications@github.com
wrote:

[image: 😭]

—
Reply to this email directly or view it on GitHub
#4575 (comment).

[bootstraponline]

There's no other way? It might be helpful to at least consider some alternatives.

[0x1mason]

Afaik, you can't do it without multiple branches. If you have an idea,
please suggest it. Here's the problem:

1. We test and release a beta on 1/1
2. On 1/2, you create a new feature and want to merge it.
3. On 1/3 I find a bug in the beta release and write a for fix it.
4. On 1/4 I want to release the fixed version of the code I just beta'd.

How can I ship code that's been beta'd AND allow you to merge new features
in the interim? That's the question. The normal solution for this problem
is to have multiple branches, but I'm certainly open to new ideas.

On Fri, Feb 20, 2015 at 6:37 PM, bootstraponline notifications@github.com
wrote:

There's no other way? It might be helpful to at least consider some
alternatives.

—
Reply to this email directly or view it on GitHub
#4575 (comment).

[bootstraponline]

How can I ship code that's been beta'd AND allow you to merge new features
in the interim?

Let's look at an actual feature I implemented. This feature wasn't merged because it was assumed master was going to become the 1.3.5 release. Instead 1.3.5 was on a branch. If a new feature isn't going to be in the current release then it should wait.

If you have an idea,
please suggest it.

I've been suggesting ideas on Slack. Maybe the current workflow is fine however clearly not everyone is on the same page.

[0x1mason]

Your idea is fine if the beta periods are short and you don't need to use
code from someone else's commit in your work. When the latter happens,
letting PRs pile up (any more than they already do) becomes a significant
problem. Branching is the async, non-blocking model, but it does have its
own complications. We're trying to keep it to minimum by only branching
during the beta periods.

I think there some miscommunication, I think partly between the sauce team
and non-saucians, though obviously @jlipps was confused so we'll need to
sort that out too.

On Fri, Feb 20, 2015 at 6:50 PM, bootstraponline notifications@github.com
wrote:

How can I ship code that's been beta'd AND allow you to merge new features
in the interim?

Let's look at an actual feature
#4467 I implemented. This feature
wasn't merged because it was assumed master was going to become the 1.3.5
release. Instead 1.3.5 was on a branch. If a new feature isn't going to be
in the current release then it should wait.

If you have an idea,
please suggest it.

I've been suggesting ideas on Slack. Maybe the current workflow is fine
however clearly not everyone is on the same page.

—
Reply to this email directly or view it on GitHub
#4575 (comment).

[bootstraponline]

It'd be great to document the current workflow somewhere so everyone knows what to expect.

[0x1mason]

Sure, that's a great idea. Fwiw, we're doing a very, very limited version of this: http://nvie.com/posts/a-successful-git-branching-model/, but only betas are getting their own branches.

[bootstraponline]

I prefer Google's approach of trunk based development. I disagree that PRs would pile up (they'd just be merged to master and then end up in the beta). In terms of not being able to use code from others, that's silly. It's still a branch so all the same git magic applies, the branch just happens to be called master. Anyway, if the other devs aren't in favor of TBD then I'm fine with keeping the branching model as long as it's documented so there aren't surprises.

[0x1mason]

@bootstraponline I'm fine with the Google approach. I don't see it as a whole lot different than what I did, according to your article: “Branch on/for Release” is the strategy. With the Google model we should already have a 1.3.6 branch to which features for the next release are being merged. Your model uses release branches, my model uses release branches, it's all a big happy family :)

[0x1mason]

Trunk Based Development (TBD) is where all developers (for a particular deployable unit) commit to one shared branch under source-control. That's what I was doing.

[bootstraponline]

I agree, it looks like the same thing.

[0x1mason]

I'll reread your article, but so far I'm def open to it.

[0x1mason]

@jlipps Take a look at the Trunk Based Development article @bootstraponline referenced. It's short. I think the approach it describes is better than what's been suggested so far. It's simple and it fits the GitHub workflow perfectly. Here's the basic flow:

1. All PRs go to master.
2. We decide to release 1.x.x, starting with the beta. Whoever is leading the release creates a 1.x.x. branch.
3. New PRs and Beta fixes continue to go to master.
4. The release leader cherry picks needed fixes from master into the release 1.x.x branch. This continues thru release, hot fixes, etc.
5. Rinse, repeat

Key points:

1. Master always has the latest code with all the bug fixes, correct versioning, etc.
2. Release branches are never merged back into master, so there's no danger of merge conflict.
3. It makes life a lot easier for everyone since we're not having to orchestrate PRs to 1.x.x-branch or an appium-next branch.

The only thing it doesn't do is let you tell from master what commits go with which release, but that information is in the release branches. I understand why you want master to be tidy, but I'm not convinced the benefits of tidiness outweigh the overall advantages of the TBD approach for a GH-based open source project, especially since the information you want is still available.

@paymand @sebv or anyone else, feel free to chime in.

[sebv]

:+1 for trunk based development, the only thing is to update our build from sourcedoc and point to the latest tested stable so that users don't attempt to use master while it is not so stable.

[paymand]

👍 for the mainline/trunk based approach. That's what we do at Opera as well. Keep a mainline/master which is of sufficient quality and branch out short-lived stablization/stable branches for releases. All fixes end up on mainline. Safe fixes are then back-ported to stable branches. We do test both stable and master though.

[jlipps]

👍 to trunk-based development