Skip to content

Instantly share code, notes, and snippets.

🤷‍♂
~~~

Stephan Bönnemann-Walenta boennemann

🤷‍♂
~~~
Block or report user

Report or block boennemann

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View onename.txt
Verifying that +boennemann is my blockchain ID. https://onename.com/boennemann
@boennemann
boennemann / ideas.md
Created Jan 7, 2016
Simply semantic-release config and increase flexibilty
View ideas.md

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
boennemann / semantic-release-setup.sh
Last active Oct 26, 2015
semantic-release setup
View semantic-release-setup.sh
#!/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
boennemann / README.md
Last active Apr 5, 2019
Pushing new releases of a legacy version with semantic-release
View README.md

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)
View package.json
{
"scripts": {
"preparepublish": "changelog",
"prepublish": "transpile && minify && docs",
"mypublsih": "npm run preparepublish && npm publish"
}
}
View slackbot.md

guys, dudes, bros

I think you mean team...

I think you mean squad..

I think you mean gang...

I think you mean pals...

@boennemann
boennemann / hybird.js
Created Jun 10, 2015
Using Babel while keeping individual commits and branches installable
View hybird.js
var main
try {
main = require('../dist/main')
} catch (e) {
require('babel/register')
main = require('../src/main')
}
// do your thing
View TRIAGING.md

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
View keybase.md

Keybase proof

I hereby claim:

  • I am boennemann on github.
  • I am boennemann (https://keybase.io/boennemann) on keybase.
  • I have a public key whose fingerprint is F70C B400 09DB A932 CE78 80E2 FC69 316C 9866 3CFE

To claim this, I am signing this object:

View test.cs
using System;
namespace bsp11
{
class MainClass
{
public static void Main (string[] args)
{
/* 1.(2P) Schreibe ein Programm, das die Fü̈llmenge eines liegenden Kreiszylinders berechnet (Formel siehe Wikipedia, Tank-Problem).
You can’t perform that action at this time.