release 1.0?
jrochkind opened this issue · 3 comments
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.
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
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.
Agree.
I'm fine with going to either approach as long as its documented and consistent.