Kimserey's blog

Setup Continuous Integration and Deployment for dotnet library with Appveyor and FAKE Last week we saw a flow to manage versioning and releases . As a continuation of last week, today I will show how we can setup versioning and releases for open source projects by configuring Appveyor and using FAKE to setup a build script. Configure AppVeyor FAKE 1. Configure AppVeyor Configuring AppVeyor is done via a yaml file appveyor.yml at the root of the repository. Then from the site https://www.appveyor.com/ , we can sign in with our GitHub credentials and add the repository to the AppVeyor projects. All the settings in the settings tab can be configured in the yaml file. appveyor.yml settings can be seen in multiple sections: global environment build test artifact deploy The global configuration is where we configure the context of the build, # 1. version: '{build}' image: Visual Studio 2017 skip_branch_with_pr: true skip_commits: files: - docs/**/* - ...

Versioning for open source library Few weeks ago I explained how Gitversion can be used to apply semantic versioning to projects based on commit and tag history. Today I will dive deeper in the purpose of versioning and introduce a flow which can be followed to version open source project libraries by looking into four important parts in the lifecycle of an open source library. Version with Semantic versioning Branching strategy and Commits Continuous Integration and Releases 1. Version with Semantic versioning Semantic versioning is ideal for versioning libraries. It is formed by three numbers {major}.{minor}.{patch} . Each number is used to indicate to the user the level of safety for upgrading the library. Upgrade of the major is risky and has chances to contain breaking changes, therefore looking at release notes or looking for migration would be recommended. Upgrade of the minor has lesser risk and can be used to show availability of new features. Upgrade of the pat...