README.md in yes_ship_it-0.0.6 vs README.md in yes_ship_it-0.1.0

- old
+ new

@@ -1,7 +1,11 @@ # Yes, ship it! +[![Gem Version](https://badge.fury.io/rb/yes_ship_it.svg)](https://badge.fury.io/rb/yes_ship_it) +[![Build Status](https://travis-ci.org/cornelius/yes_ship_it.svg?branch=master)](https://travis-ci.org/cornelius/yes_ship_it) +[![Code Climate](https://codeclimate.com/github/cornelius/yes_ship_it/badges/gpa.svg)](https://codeclimate.com/github/cornelius/yes_ship_it) + *The ultimate release script* Whenever the answer is "Yes, ship it!" you will need `yes_ship_it`, this tool. It is the ultimate helper in releasing software. @@ -74,13 +78,17 @@ Many software projects will have specific needs for their releases. These can be broken down and reflected in additional assertions. Adding assertions is easy. There is a well-defined API for it. -There is no supported plugin concept. The idea is that all assertions ship with -`yes_ship_it`. This will maximize the value for the community of people who ship -software. The project is very open to include new assertions. Just submit a pull -request. `yes_ship_it` will ship it with the next release. +You can extend yes_ship_it by writing local assertions as plugins. Use the +command `yes_ship_it plugin` to generate and manage them. + +While plugins can be useful for very special assertions or as a start for new +ones, it would be great to generalize them and ship them with `yes_ship_it`. +This will maximize the value for the community of people who ship software. +The project is very open to include new assertions. Just submit a pull request. +`yes_ship_it` will ship it with the next release. ## Testing Testing a tool such as `yes_ship_it` is not easy because its prime functionality is to interact with other systems and publish data. There are unit tests for the