Release schedule post version 1.0

(Sam Saffron) #21

Yeah I am fine to scrap the Cannery idea, I can see issues cropping up for us with it.

(Tuan Anh Tran) #22

What do u mean by no version in params?

I’m seeing this right now.

  ## Which Git revision should this container use?
  version: HEAD

(Robin Ward) #23

I agree there’s no reason to not use the tests-passed branch.

At that point if we have 3 channels it’s the same as Ember, and very similar to Chrome only we’d be using different names.

I suggest we use the same names those projects do. I don’t think it makes sense to reinvent terms for what is already in use in two projects we depend on!

  • canary: our current tests-passed branch can be renamed to this.
  • beta: our weekly bumps
  • release: our stamped, tagged releases

Again, why not use the 6 weeks that Chrome and Ember use rather than 8 weeks? I think there is value in sticking to the conventions others have set up.

(Jeff Atwood) #24

I agree with that, except “canary” is an awful meaningless name. I suggest we use “latest” instead as that is actually understandable. If I said to someone “you should be on latest to get those fixes” that is far easier to understand than “you should be on canary to get those fixes”. WTF?

I know they think canary in the coalmine is all clever and stuff, but it is the bad pointlessly confusing kind of clever.

(Jens Maier) #25

I actually like the analogy, but for different reasons. ‘Canary’ evokes the image of a little bird with fancy, colorful feathers… bit given the chance it’ll pick up your data and fly out of the window with it while pooping on your hand.

Yeah. I have some bad experiences with pet birds. :scream:

(Dave McClure) #26

Plus, @sam can’t spell it right :wink:

(Jon Watte) #27

How about a single branch (mainline) and always shipping that? With proper unit and functional testing, and attention to detail before committing, this would be the nimblest process possible.

No, seriously – if something’s wrong, that should be quickly found, and quickly fixed. If everything is on mainline, a fix if something should escape the barrage of unit tests is only a quick revert away.

We’ve used continuous deployment successfully at IMVU for almost ten years now, and I would not want to go back to branches, at least as long as the target is web.

(Tomo Vukasović) #28

Latest sounds great!

(Tuan Anh Tran) #29

I actually prefer chrome release style. Not all of us want to ride on master branch (well i do but i believe i belong to a rather small subset of userbase here). Some of us may prefer a well tested release if their forum is huge and cannot tolerrate any downtime.

(InsaneMosquito) #30

Agreed. I imagine that many don’t want to risk a broken forum when they click “Update”. The beta and canary branches are for those more inclined to testing and developing, while a stable branch is for people that just want it to work, and work reliably.

(Robin Ward) #31

I think there is value sticking with the terms other projects have adopted. I’m a big fan of convention and “Canary” seems to be the term people are using for this channel. Why not use what people already know?

(Jon Watte) #32

Some of us may prefer a well tested release

Why isn’t every commit a well tested release?

(Jens Maier) #33

Because Git is not a release platform, it’s a tool for developer collaboration.

(Jon Watte) #34

Yes, you can push between developers with git if those developers are collaborating on a particular feature.

Once you push to general consumption (developers or customers,) it would stand to reason that you have coverage with acceptance tests (easy to do for web apps! check saucelabs or similar) and unit tests (rails has lots of support for this.)

I’ve worked in many places that have used various release branch mechanisms, and it’s always been work to manage those, and developers end up using QA and release branches as an excuse to not write good automated tests. I’ve also worked at a place where each commit to master goes live in front of customers, assuming it passes all automated tests. This site has been around for ten years and has tens of millions of monthly users, and having solid automated testing coverage is a significant asset to the engineering organization and company.

So, again: Why wouldn’t every commit to master be a stable commit, well tested (automatically) and ready for use?
The smaller such commits are, the less likely they are to break, and the easier they are to undo if they end up breaking something. (The four-branches, a-month-to-build-a-release monster processes end up breaking things in production anyway, in my experience.)

(Jens Maier) #35

So it boils down to nomenclature. You expect commits in master to be stable and tested, Discourse chose to follow a different branch naming scheme: to wit, tests-passed, which automatically follows master when tests pass.

Is that really such a big deal?

(Jon Watte) #36

If you have tests-passed, then why do you need all the other beta/release/canary branches? Why are you not confident in test-passed?

(Jens Maier) #37

Ah, I see, you still believe in the myth of the fool-proof unit test.
This is neither the place nor the time for a debate on test completeness, so I’m not going to pursue this further.

Still, after all is said and done, you do realize that you will be getting exactly what you asked for, right? Canary, if that name even sticks, is a mere rename of the tests-passed branch. Nobody’s forcing you to stick to tagged releases.

(Sam Saffron) #38

Canary usually means a daily build, which is not our intention at all with this channel. I really like @codinghorror’s suggestion of naming it “latest”, it is less scary and properly represents what we mean here. We will still be deploying latest to customers even post v1. Ember, Chrome and Firefox would rarely recommend general population use Canary.

(Jeff Atwood) #39

Plus we’ve been calling it “latest” for about a year now, so it reflects the terms we actually use, and what people seem to understand just fine.

(Jon Watte) #40

There is no such thing as a fool-proof automated test suite, any more than there is a fool-proof release branch system. However, automated acceptance tests plus automated unit tests can test at least as much as a human following a written test plan, but tirelessly, and for each commit. Having built and worked with both kinds of release systems on major products, I would say that the end results of pushing code live ASAP with very strong automated testing beats the end results of using a branch-heavy, delay-inducing “traditional” release process.

I’m offering this perspective from having worked on both, deeply, for a long time. I understand that you have experience with the branch-heavy version, but I don’t see understanding of the alternative. Which is fine; you’re probably a lot more committed to this particular project than I am; all I can do is share pretty hard-fought learnings hopefully for the better good.

I don’t think that having a “latest” and a “tests-passed” and a “beta” and a “canary” and a “stable” branch (or some greater-than-one subset of those branches) will achieve the same thing. The reason is, when there is a manual testing process, and/or an induced delay, developers will, on average, spend less time verifying their own code and building robust functional and unit tests before they commit the code in the first place. And catching bugs before they’re committed is always the best place to catch them. In other words: the necessary changes to engineering process for a “master is release” system is of significant value!