develop and document versioning protocol #254

jantman opened this Issue Feb 6, 2017 · 0 comments


None yet

1 participant

jantman commented Feb 6, 2017

Many users are running ALC through scheduled jobs, and likely have manually-maintained (or at least not *:*) IAM policies. As such, releases that require new permissions may be problematic.

Adopt semver (well, officially...)

Specifically document a versioning promise around:

  • Changing the names of existing services or limits is considered an incompatible API change (major version bump)
  • Changing the signatures or argument types of any public (non-underscore-prefixed) methods is considered an incompatible API change (major version bump) (this seems obvious, but was done in 0.8.0 in a pretty bad way).
  • Adding new limits is considered a backwards-compatible API change (minor version bump), except:
  • Adding new required IAM permissions is an incompatible API change (major version bump); this will likely mean that all new services, and many new limits, result in a new major version. Oh well. I'd rather announce the release of version 387 than break someone's scheduled run unexpectedly.
  • Changing the version of any dependency is considered an incompatible API change
  • Anything that would prevent usage like the Python examples (i.e. iterating over services and results) from working as it currently does is an incompatible API change.
@jantman jantman added this to the 0.8.0 milestone Feb 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment