Automated Publish

[david-driscoll]

From the last team meeting I said I would comment with information on automating things. Basically travis will set environment variables such that when you create a github release (which is a git tag as well) you can run your publish script automagically.

Here are some the scripts I've used with OmniSharp.

At the end of a build publish.sh is called. Then publish.sh looks to see if the commit was a git tag $TAG_COMMIT, and then does the publish operation.

As an aside here travis fires off a pull request to another repo (could be the same repo)

[benlesh]

This makes sense, but what about maintaining multiple branches for stable, versus, beta, vs nightlies?

We'd want something were we can promote from master (nightly) to beta, then beta to stable. I guess we could roll something like that into the publish.sh script? Like... "If the tag was beta, but is now not beta, then merge the branch over to stable"?

[benlesh]

And to be clear, we don't need "nightlies" necessarily, just a canary label or something that publishes the bleeding edge.

... then again, I guess the daring could just use npm git dependencies.

[david-driscoll]

with the build using git dependencies is problematic I've found.

We could totally fork on standard branch names, and those would just lead to typical npm labels.

next - next patch release
beta - next minor
canary - next major

The big problem will be managing the differences between the branches, ensuring that patches to go stable and then those get merged from stable to beta then master. That could be managed with some scripting as well. If for example we have a small patch for a typings fix, the script would attempt to merge that into beta, if there are no conflicts, then it merges and pushes. If there are conflicts, it opens a PR.

[benlesh]

We'll get here some day. Closing it so we can have a discussion at a later point.