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