boennemann

Triage new issues/PRs on github

This document illustrates the steps the Hoodie community is taking to triage issues. The labels are used later on for planning releases. If you want to help by sorting issues please leave a comment here asking to join the triaging team.

Triaging Process

This process based on the idea of minimizing user pain from this blog post.

1. Open the list of non triaged issues

boennemann

var main

try {
  main = require('../dist/main')
} catch (e) {
  require('babel/register')
  main = require('../src/main')
}

// do your thing

boennemann

guys, dudes, bros

I think you mean team...

I think you mean squad..

I think you mean gang...

I think you mean pals...

boennemann

{
  "scripts": {
    "preparepublish": "changelog",
    "prepublish": "transpile && minify && docs",
    "mypublsih": "npm run preparepublish && npm publish" 
  }
}

boennemann

If you have a package where a lot of people are still using a legacy version of it you might want to keep pushing (security-)fixes to that "branch".

Let's say the "latest" version of your package is "5.4.0", but there is as significant amount of people still using "4.7.4" – the last version you released before doing "5.0.0".

You found a critical bug in "5.4.0" and push it as out as "5.4.1", but it applies to "4.7.4" as well and so you want to do "4.7.5".

Assuming you have semantic-release already set up, you can follow these steps to get that "4.7.5" legacy support release out.

1. Go to the relevant commit: git checkout v4.7.4
2. Create a new branch from it: git checkout -b 4.x (You can choose any branch name, just make sure to use the same in step 3)

boennemann

#!/bin/sh

export GITHUB_TOKEN=$GH_TOKEN

curl -Lo travis_after_all.py https://git.io/vLSON
python travis_after_all.py
export $(cat $(pwd)/.to_export_back 2> /dev/null) &> /dev/null

rm travis_after_all.py .to_export_back

boennemann

The current plugin system aims to make every step of semantic-release customizeable. There is a lot of overhead to this though.

Idea:

1. Remove verifyConditions.
2. Hardcode one check that implements every CI server out there. (Mappings for each service are trivial to add, much like in https://github.com/auchenberg/volkswagen)
3. Add an option to surpass this check.

With this it would "just work™" on any CI server. If there is custom behavior required this can simply be run before the semantic-release command: e.g. verify-unicorns && semantic-release pre && npm publish && semantic-release post.

boennemann

Verifying that +boennemann is my blockchain ID. https://onename.com/boennemann