versioning   7044

« earlier    

Staying on Top of Changes in GraphQL | GitHub Developer Guide
"Staying on Top of Changes in GraphQL
May 3, 2018 xuorig
To provide a more seamless experience we prefer to continuously evolve our schemas rather than using API versioning. Continuous evolution allows us to iterate faster and provide our integrators with new schema members more often. We do our best to avoid breaking changes, but sometimes it's necessary to offer an unversioned API.

We strive to provide the most stable APIs to our integrators and to provide transparency about new developments. This is why we recently shipped the brand new Breaking Changes page, which announces future breaking changes to our GraphQL schema.

Internally, our engineers mark certain schema members as deprecated using a Ruby API on top of the graphql-ruby gem. Using the changes metadata provided by our engineers, we automatically compute removal dates and generate this breaking changes page, meaning you'll always get up to date information."
github  graphql  versioning  schemas  apis  omgwtf 
5 days ago by earth2marsh
Breaking Changes | GitHub Developer Guide
"Breaking changes are any changes that might require action from our integrators. We divide these changes into two categories:

Breaking: Changes that will break existing queries to the GraphQL API. For example, removing a field would be a breaking change.
Dangerous: Changes that won't break existing queries but could affect the runtime behavior of clients. Adding an enum value is an example of a dangerous change.
We strive to provide stable APIs for our integrators. When a new feature is still evolving, we release it behind a schema preview.

We'll announce upcoming breaking changes at least three months before making changes to the GraphQL schema, to give integrators time to make the necessary adjustments. Changes go into effect on the first day of a quarter (January 1st, April 1st, July 1st, or October 1st). For example, if we announce a change on January 15th, it will be made on July 1st."
github  changes  apis  breaking  versioning  graphql  omgwtf 
5 days ago by earth2marsh
GraphQL Best Practices | GraphQL
While there's nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.

Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.

In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has lead to a common practice of always avoiding breaking changes and serving a versionless API."
versioning  apis  graphql  schemas 
5 days ago by earth2marsh
Why The New York Times TL;DR’d its own 14,218-word Trump investigation » Nieman Journalism Lab
at the same time that it published the investigation that was a year in the making, it also aggregated itself — publishing “11 takeaways from the Times’s investigation into Trump’s wealth.” The TL;DR version is by the same authors as the full investigation (Russ Buettner, Susanne Craig, and David Barstow), and, at over 2,500 words, it’s pretty much a longread of its own. There’s also this much shorter interactive version, with audio and video.
longform  listicle  nytimes  interactive  versioning  chunking 
15 days ago by paulbradshaw
Versions — Git for Designers
Система версионирования макетов и шаблонов для дизайнеров от Sympli. Её анонсировали в прошлом году, теперь она доступна для всех.
UX  collaboration  versioning  tools 
16 days ago by jvetrau

« earlier    

related tags

2012  2015  2017  365  _win32_winnt  abi  api  apis  apistrat  aws  backward  best-practices  bestpractices  blog  breaking  bug  business_components  calendar  ccc  change  changes  cheatsheet  chunking  clojure  code  coink  collaboration  commandline  commits  compatibility  compile  components  continuousdelivery  contracts  couchdb  critical  criticism  cvs  data  database  dep  deployment  design  designsystem  development-process  development  devops  diffing  discussion  distributed  docker  documentation  elixir  failure  files  geek  git  github  gloang  go  golang  graph  graphics  graphql  haskell  history  howto  humour  ilstu  images  incompatibility  incompatible  inspiration  interactive  interesting  isolation  issue  java  javascript  jdk  jenkins  journalism  jupyter  lambda  langauge  language  languages  legacy  lein  leiningen  lenses  library  link  listicle  logidze  longform  macro  macros  magic  maintenance  manager  maven  minimal  modeling  ms  mvn  nathancurtis  nbextension  neo4j  news  newsdiffs  node-js  nodejs  npm  numbers  nytimes  office-addin  office  omgwtf  online  openaccess  opensource  operating  organization  package-manager  package  packaging  peoplesoft  pipelines  plugin  postgres  presentation  programming  pypi  python  rails  record  refactoring  reference  resources  responsability  rest  revision  richhickey  ruby  rust-lang  rust_lang  sat  schemas  selection  semantic-versioning  semantic  semver  setuptools  shared  sharepoint  single  software-distribution  software  softwaremanagement  spm  sqlite  srp  staging  standards  strategy  subversion  svn  swift  swiftpackagemanager  system  tag  tagging  targetver.h  technology  tester  timestamp  tips  tm351  tool  tools  tos  tutorial  tutorials  twitter  unix  updates  utilities  ux  vcs  version-management  version  version_control  versioncontrol  versioninfo  versions  vgo  warelogging  webdev  wikipedia  win32  windows  winver  wordpress  workflow  writing  xcode 

Copy this bookmark: