Discussion about versioning

[prrrnd]

The README mentions that this gem adheres to semantic versioning, but the CHANGELOG says otherwise.

I have a decent test coverage in a codebase using active_model_serializers, but even a patch version bump can be nasty.

I would like to open a discussion for improvements regarding this issue, or hear how others handle it.

[bf4]

@prrrnd what makes you say it doesn't keep semver? (This has come up before fyi). We're pre-1.0. (which is not unusual for projects that began pre-semver)

[prrrnd]

@bf4 Semver describes that pre-1.0 should not be used in production. This gem has over 7M downloads (source), yet its version number is misleading and just the fact that several developers reported this as an issue should question the responsibility of the maintainers.

Once on 1.x.y, nothing prevents from making structural changes either. That's what a major version bump is for.

Please consider incrementing the major version. It is relatively low cost for the maintainers, and can save hours to many developers out there.

[benhutton]

:+1: for shipping 1.0.0

Doing our weekly bundle update on our app... This 0.10.5 -> 0.10.6 upgrade is causing me much more grief than the rspec 3.6 upgrade.

[bf4]

@benhutton

Doing our weekly bundle update on our app... This 0.10.5 -> 0.10.6 upgrade is causing me much more grief than the rspec 3.6 upgrade.

what problems are you having? I upgraded as well and didn't have any. (I dog food our app :)

[bf4]

@prrrnd I assume you're referring to semver.org's admonition to release 1.0.0 if the gem is used in production. Like I said, this gem predates semver.org. So, just like Rails 4.1 -> 4.2 is a major change, rather than minor, 0.8 -> 0.9 -> 0.10 are major changes. This is not unusual for older projects.

Now, I'm not saying I like it this way. Just that it's where a lot of older libs are. We want to release a 1.0.0, but there are issues with 0.10 that are preventing us from doing that. It has an unnecessarily high maintenance burden.

[benhutton]

@bf4 2 things:

1. https://github.com/rails-api/active_model_serializers/pull/2119 caused our tests that leveraged unpersisted (for speed) ActiveRecord objects to fail (since they don't have an id)
2. For whatever reason, before this release we were able to get anid inside of an attributes hash, and now the id is only outside of it. I'm now investigated how badly we need that id inside of attributes (do our ios or android apps expect it?), or can we just update our specs to match and use things as they are now.

[benhutton]

@bf4 wrt semver.....

When the README says that this project adheres to semver, what about semver is it currently adhering to? Or should the README be updated to say something like, "Once 1.0.0 is shipped, this project will adhere to semver"?

[bf4]

@benhutton I understand the sentiment that we shouldn't be on pre 1.0 anymore. SimpleCov is widely used and is still pre 1.0, which the maintainers also intend to remedy. However, unless you can point me to something that says AMS is 'doing it wrong' in a specific case, rather than aspirational, my experience is that its versioning is consistent with the spec and many other projects.

I don't think either of us (hopefully) are particularly interested in litigating the definition. We just want code that isn't surprising. 0.9.0 -> 0.10.0 is documented as a breaking change while 0.10.0 -> 0.10.1 is a minor change or patch, which is why it is recommended that your gemfile have ~> 0.10.6.

I'm interested in how the attributes/id behavior changed. That sounds like a bug that should be reported outside of this issue.