3 ms·

Sounds like GitHub just committed to only supporting their api for two years. That sucks. I don’t think companies have to support forever but I don’t like the

Sounds like GitHub just committed to only supporting their api for two years. That sucks. I don’t think companies have to support forever but I don’t like the idea of having to rework my integrations every two years. Also specifying a date is very clunky. I’d rather they use semver (like a non-barbarian) and stick with breaking changes going into a major release.

aliqot 4y ago
show them who's boss and ask for your money back.
- prepend 4y ago
  I spend a lot of money on GitHub. And I use their api a decent amount. I won’t ask for my money back but it definitely makes me think more about GitLab and other competitors.
  - aliqot 4y ago
    I was with you until Gitlab.
mberning 4y ago
This is the goofiest API versioning scheme I have ever heard of. Reminds me of opening a java project and finding stuff like joda-time-2004-11.jar.
madeofpalk 4y ago
what's the difference between one string (a date) and other string (something vaguely resembling a number)?
- deleted 4y ago
  [deleted]
- prepend 4y ago
  Semver contains info by looking at the values. 2.0 introduces breaking changes over 1.7.1.3. What does 2022-11-28 vs 2022-11-30 mean? Or how many releases are between 2022-11-28 and 2042-11-28? I’m sure there’s a docs page spelling it out with details, but being able to compare two versions and tell if your code will work is pretty handy.
  - madeofpalk 4y ago
    They're only using versioning to indicate breaking changes though. There will never be minor or patch versions in this semver, only ever major (breaking) changes. They're saying "if the version is different in any way, your code might not work because there are breaking changes". How much the major version changed (v2 -> v3 vs v3 -> v9) doesn't actually tell you how many changes there were. In that way it's almost identical to using major-version-only semver, vs dates.
- timrogers 4y ago
  Author here. We went for dates because they allow you to see, at a glance, roughly how old the version you're using is. We didn't think that semver made sense because, in our versioning system, all new versions are breaking (i.e. major). Hope that makes sense!
Aeolun 4y ago
You’d only have to rework your code if you are using the API they changed.
abraham 4y ago
> After two years, we reserve the right to retire a version, but in practice, we expect to support historic versions for significantly longer than this. Consider v3 has been around for a decade, they seems likely to last longer than 2 years.
- prepend 4y ago
  This is an example of when not to set a limit. There wasn’t a previous commitment to maintain v3, so why add one now? And why only 2? If they intend to maintain them for 10 years then don’t set a specific timeframe and just stick to whatever their current nebulous language is.
  - timrogers 4y ago
    Author here. We just wanted to provide a guarantee to reassure users that the introduction of API versioning wasn't going to mean rapid deprecations of versions. We thought that giving a guaranteed minimum lifetime was a reasonable way to do that.
pbreit 4y ago
Current version has lasted for 10+ years but now that they hav versioning, might be gone in 2. Progress!

aliqot 4y ago

show them who's boss and ask for your money back.

prepend 4y ago
I spend a lot of money on GitHub. And I use their api a decent amount. I won’t ask for my money back but it definitely makes me think more about GitLab and other competitors.
- aliqot 4y ago
  I was with you until Gitlab.

mberning 4y ago

This is the goofiest API versioning scheme I have ever heard of. Reminds me of opening a java project and finding stuff like joda-time-2004-11.jar.

madeofpalk 4y ago

what's the difference between one string (a date) and other string (something vaguely resembling a number)?

deleted 4y ago
[deleted]
prepend 4y ago
Semver contains info by looking at the values. 2.0 introduces breaking changes over 1.7.1.3. What does 2022-11-28 vs 2022-11-30 mean? Or how many releases are between 2022-11-28 and 2042-11-28? I’m sure there’s a docs page spelling it out with details, but being able to compare two versions and tell if your code will work is pretty handy.
- madeofpalk 4y ago
  They're only using versioning to indicate breaking changes though. There will never be minor or patch versions in this semver, only ever major (breaking) changes. They're saying "if the version is different in any way, your code might not work because there are breaking changes". How much the major version changed (v2 -> v3 vs v3 -> v9) doesn't actually tell you how many changes there were. In that way it's almost identical to using major-version-only semver, vs dates.
timrogers 4y ago
Author here. We went for dates because they allow you to see, at a glance, roughly how old the version you're using is. We didn't think that semver made sense because, in our versioning system, all new versions are breaking (i.e. major). Hope that makes sense!

Aeolun 4y ago

You’d only have to rework your code if you are using the API they changed.

abraham 4y ago

> After two years, we reserve the right to retire a version, but in practice, we expect to support historic versions for significantly longer than this. Consider v3 has been around for a decade, they seems likely to last longer than 2 years.

prepend 4y ago
This is an example of when not to set a limit. There wasn’t a previous commitment to maintain v3, so why add one now? And why only 2? If they intend to maintain them for 10 years then don’t set a specific timeframe and just stick to whatever their current nebulous language is.
- timrogers 4y ago
  Author here. We just wanted to provide a guarantee to reassure users that the introduction of API versioning wasn't going to mean rapid deprecations of versions. We thought that giving a guaranteed minimum lifetime was a reasonable way to do that.

pbreit 4y ago

Current version has lasted for 10+ years but now that they hav versioning, might be gone in 2. Progress!