Gem release strategy

32 views
Skip to first unread message

Iain Beeston

unread,
Nov 29, 2014, 11:53:23 AM11/29/14
to ruby-jso...@googlegroups.com
I'm just wondering, what should the process be for releasing the gem? There has been a lot of refactoring since the last release (and a new dependency added - addressable) and it seems like a release would be a good idea, before there are more changes.

However, what's the best way of deciding when to do this. In theory I can release the gem but I feel like there should be some discussion about whether any active pull requests should be merged first. Github has milestones, which are good for this, or we could raise an issue to request a release, or do it on here (the Google Group).

Thoughts?

Kyle Hargraves

unread,
Nov 30, 2014, 12:28:47 PM11/30/14
to Iain Beeston, ruby-jso...@googlegroups.com
Release at will, IMO. Especially for bugfix releases, which I will start helping to release more often: most of the changes since 2.4.1 prolly coulda been 2.4.x releases; like you said, it's mostly been refactoring up until RST-J's addressable change, which I suppose merits a 2.5.0. I like the idea of milestones, and it'd give us a quick reference for "is anything blocking another release". I'm a lot more likely to notice something on Github than in my ever-growing inbox. =)

k


--
You received this message because you are subscribed to the Google Groups "Ruby JSON Schema Library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-json-sche...@googlegroups.com.
To post to this group, send email to ruby-jso...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-json-schema/2de1330b-a8c0-4555-9b5b-dcd560bb6985%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kenny Hoxworth

unread,
Nov 30, 2014, 12:31:25 PM11/30/14
to Kyle Hargraves, Iain Beeston, ruby-jso...@googlegroups.com
I second Kyle's suggestion. I prefer many small releases to few large ones. keeps the delta small and potential breakages at a minimum. 
To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-json-schema/CAFSHhdNGMgSj1NQGb2Ez7oYg5_A9KUtoALq2b3SJp3iF47B%3D5A%40mail.gmail.com.

Max Lincoln

unread,
Dec 5, 2014, 12:16:24 PM12/5/14
to ruby-jso...@googlegroups.com, p...@krh.me, iain.b...@gmail.com
This all sounds good to me. Especially "many small releases to few large ones".

However, it'd be nice if there was a changelog or release notes - at least for major and minor releases (assuming you're following http://semver.org/). I saw a minor release (2.4 -> 2.5) which in semver is used when you "add functionality in a backwards-compatible manner". So I came to the site to try and find out what the new features were, but I couldn't find any obvious notes. I don't care too much about release notes for patch versions. If I want to see every single bugfix I can browse the issues/PRs on GitHub.

Cool but unnecessary tip: you can associate notes with releases on GitHub
  For example, compare: json-schema (no notes) w/ fog.
  Fog uses a couple rake tasks to generate and upload the notes. You can also do it manually.

On Sunday, November 30, 2014 12:31:25 PM UTC-5, Kenny Hoxworth wrote:
I second Kyle's suggestion. I prefer many small releases to few large ones. keeps the delta small and potential breakages at a minimum. 

On Sunday, November 30, 2014, Kyle Hargraves <p...@krh.me> wrote:
Release at will, IMO. Especially for bugfix releases, which I will start helping to release more often: most of the changes since 2.4.1 prolly coulda been 2.4.x releases; like you said, it's mostly been refactoring up until RST-J's addressable change, which I suppose merits a 2.5.0. I like the idea of milestones, and it'd give us a quick reference for "is anything blocking another release". I'm a lot more likely to notice something on Github than in my ever-growing inbox. =)

k
On Sat, Nov 29, 2014 at 10:53 AM, Iain Beeston <iain.b...@gmail.com> wrote:
I'm just wondering, what should the process be for releasing the gem? There has been a lot of refactoring since the last release (and a new dependency added - addressable) and it seems like a release would be a good idea, before there are more changes.

However, what's the best way of deciding when to do this. In theory I can release the gem but I feel like there should be some discussion about whether any active pull requests should be merged first. Github has milestones, which are good for this, or we could raise an issue to request a release, or do it on here (the Google Group).

Thoughts?

--
You received this message because you are subscribed to the Google Groups "Ruby JSON Schema Library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-json-schema+unsubscribe@googlegroups.com.
To post to this group, send email to ruby-json-schema@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby JSON Schema Library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-json-schema+unsubscribe@googlegroups.com.
To post to this group, send email to ruby-json-schema@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages