Skip to content

Instantly share code, notes, and snippets.

@markmcspadden

markmcspadden/gist:1590406

Created January 10, 2012 18:33
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save markmcspadden/1590406 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save markmcspadden/1590406 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. markmcspadden revised this gist Jan 10, 2012. 1 changed file with 12 additions and 4 deletions.
    16 changes: 12 additions & 4 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,12 +6,20 @@ Josh Susser - @markmcspadden can you expand on that? I don't quite understand wh

    --

    I've experienced several situations where there's an internal service (usually Rails, sometimes Sinatra or Rack) that has a corresponding gem. Often I or whoever wrote the service maintains both the service and the gem.
    I've experienced several situations where there's an internal service
    (usually Rails, sometimes Sinatra or Rack) that has a corresponding gem.
    Often I or whoever wrote the service maintains both the service and the gem.

    You would think this makes for easier maintenance, versioning, and releases...I mean...you know everything about both...but you also know everything about both. I follow the standard major.minor.patch...but usually end up never feeling great about either side of it.
    You would think this makes for easier maintenance, versioning, and releases...
    I mean...you know everything about both...but you also know everything about both.
    I follow the standard major.minor.patch...but usually end up never feeling great
    about either side of it.

    Maybe it's the patch version that's problem here. Often the patch numbers could vary greatly between the gem and the service...but it "feels" like 1.2.1 of the gem "should" match to 1.2.1 of the service.
    Maybe it's the patch version that's problem here. Often the patch numbers could vary
    greatly between the gem and the service...but it "feels" like 1.2.1 of the gem
    "should" match to 1.2.1 of the service.

    I may just be over thinking/obsessing here...thanks for letting me talk through this a bit.
    I may just be over thinking/obsessing here...thanks for letting me talk
    through this a bit.

    - Mark
  2. markmcspadden created this gist Jan 10, 2012.
    17 changes: 17 additions & 0 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,17 @@
    In response to:

    Josh Susser - The @rubyrogues topic for tomorrow is Versioning and Release Process. Any questions or particular things you'd like to see us address?
    Mark McSpadden - @joshsusser @rubyrogues The versioning/release dance between self maintained services and gems. (When you own the service and the gem.)
    Josh Susser - @markmcspadden can you expand on that? I don't quite understand what you're asking. @rubyrogues

    --

    I've experienced several situations where there's an internal service (usually Rails, sometimes Sinatra or Rack) that has a corresponding gem. Often I or whoever wrote the service maintains both the service and the gem.

    You would think this makes for easier maintenance, versioning, and releases...I mean...you know everything about both...but you also know everything about both. I follow the standard major.minor.patch...but usually end up never feeling great about either side of it.

    Maybe it's the patch version that's problem here. Often the patch numbers could vary greatly between the gem and the service...but it "feels" like 1.2.1 of the gem "should" match to 1.2.1 of the service.

    I may just be over thinking/obsessing here...thanks for letting me talk through this a bit.

    - Mark