release 1.0?

[jrochkind]

This is being used by a variety of apps in production.

Would it make sense to do a release marked 1.0, with corresponding commitment to backwards compat in 1.x? It would make my dependency management somewhat easier. It's hard to be depending on so many pre-1.0 gems with no expectation of avoiding backwards incompat in any subsequent releases at all.

[mejackreed]

Great concern here, what then would you consider a breaking change? Changes in tracking openseadragon or just things that change the way that openseadragon-rails wraps it?

We have the same challenge in https://github.com/sul-dlss/mirador_rails

[jrochkind]

good point. But it doesn't go away calling it 0.x, right?

I guess a breaking change would be an API change to the apparatus that this gem adds on top of openseadragon (eg helpers like openseadragon_picture_tag).

I guess I'd bump the major version number of this gem if it bumps the openseadragon version by a major version number too.

Some people version 'wrapper' gems like this based on the original dependency version. So this gem might be '2.2.1' now -- they add a fourth version segment when bugfixes are needed to the gem wrapper. That's an option, but I've never been totally fond of it. There isn't a great solution for versioning 'wrappers' like this, but I think the suggestions above this paragraph are what I'd lean towards.

Either way, the 0.x version number suggests this is not production-ready, which is not true. Even if no decisions are made about what's considered a breaking change, I suggest it's time to call it 1.0.

[mejackreed]

Agree.

I'm fine with going to either approach as long as its documented and consistent.