Release 3.0

[lagartoflojo]

Pull Request Checklist

General

• Update Changelog following the conventions laid out on Keep A Changelog

• Update README with any necessary configuration snippets

• Binstubs are created if needed

• RuboCop passes

• Existing tests pass

Purpose

• Cut a new version of the gem.
• Does not change, add or remove any functionality from the previous version.
• Updated instructions to get chat_id
• Update link to Changelog guidelines
• Update sensu-plugins to ~> 2.7, which includes breaking changes
• Update Rubocop to latest, and fix violations
• Fix strictness of rest-client gem dependency
• Remove obsolete Gemnasium badge
• Fix typo in 2.0.1 changelog header
• Remove support for Ruby < 2.3 per the Sensu Plugins policy

[lagartoflojo]

@majormoses if you have some time, I'd appreciate your input on this one :)

[majormoses]

Related issues for tracking efforts on known CVEs:

• [CVE-2017-17042] Update ruby plugins for vulnerable yard dependency community#97
• [CVE-2017-8418] Update ruby plugins for vulnerable rubocop dependency community#77

[majormoses]

This looks really good though I have some feedback. Apologies if I have not spent enough time either help documenting processes or go over them with you. Also I will be traveling tomorrow for the holidays and probably won't respond until Saturday.

[majormoses]

Will probably need to adjust the date when you have addressed my comments.

Typically we do the changes in a branch and leave everything under ## [Unreleased] without touching the version file. There are several reasons we update the versions and dates post acceptance of the change:

• PRs are not a FIFO queue, as such versioning them prior to acceptance leads to needing to ask people to rebase more often
• we might disagree on impact of change (in this case we don't)
• we might choose to lump several PR changes into a single release to reduce the number of rebases we ask users to make when they are touching the same files.
• we date the release rather then when the contribution was submitted, PR review and acceptance has no SLA and is not guaranteed to be merged within the same day

[lagartoflojo]

Got it, thanks for the explanation!

[lagartoflojo]

Thanks a lot for the review!

Who should remove the "Status: Awaiting Response" label once I've responded? :)

[majormoses]

Who should remove the "Status: Awaiting Response" label once I've responded? :)

In most cases since users don't have the ability to remove the label whoever was the initial reviewer should but since you have access you can remove it.

[majormoses]

LGTM

[majormoses]

I will reply back with a link to any commits/changes that need to be made prior to release and the release process so you can do this in the future.

[majormoses]

Looks like the only thing that was missing was updating the diff links: 6c99cbd

[majormoses]

So the process looks like this:

1. update changelog, versions, and if applicable readme
2. commit them with something like this:

 $ git commit -am 'prep for 3.0.0 release'
 [master 6c99cbd] prep for 3.0.0 release
 1 file changed, 2 insertions(+), 1 deletion(-)

3. push the change to master:

$ git push 
warning: not sending a push certificate since the receiving end does not support --signed push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 986 bytes | 986.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
reate 3.0.0To github.com:sensu-plugins/sensu-plugins-telegram.git
 2ab6341..6c99cbd  master -> master

4. create the actual release, if tests pass it will automatically push to rubygems:

$ hub release create 3.0.0

https://github.com/sensu-plugins/sensu-plugins-telegram/releases/tag/3.0.0

https://travis-ci.org/sensu-plugins/sensu-plugins-telegram/builds/458202673

[majormoses]

I will check back to see later if it built as it looks like we have clogged up our travis builds for the moment. While its not required I generally like to add a link to the actual release published to rubygems. The main reason for this is that it lets people know that after going through the review process their change has been released/published in a timely manner.

[majormoses]

released: https://rubygems.org/gems/sensu-plugins-telegram/versions/3.0.0

[majormoses]

My general rule is that except in extreme cases releases should be cut within 24 hours of acceptance of a PR. Generally I do it immediately after but sometimes for example if travis is having issues we need to delay it.

[lagartoflojo]

Excellent, thanks a lot for the quick replies and information! I thought we'd have to wait till Saturday 😉

[majormoses]

@lagartoflojo your welcome I wanted to set the expectation since I had no idea what the plans with the family were so was unsure what kind of downtime I would have.