Is there deadline to move to versioning API?

Solved
Shopify Staff
Shopify Staff
15 3 9

Hi @casperb, there is currently no way to get the newest stable version. I'm not sure why you'd want that, since it would risk your app breaking every 3 months? We could definitely add this if there's a use case I'm not thinking of though.

 

Evan

1 Like

Well, the same is true for not setting a version and getting the oldest stable version. That could also break every 3 months, but now just at a later moment. If you as a developer are not going to manually bump the version every time, it would be better to let it crash as soon as possible. In that situation you can manually point to the previous version, fix it on the client side, and go to the latest version again.

 

If you are on the oldest version and you experience a breaking change, there is no way to go back to the previous version to fix it in a couple of days or weeks. At that moment you are being forced to fix it right away.

 

The way I see it, oldest and newest are basically the same, but newest has the above upsides without any extra downsides. Especially for little apps that you don't work on that often, I would choose newest. On big applications I would point to a specific version.

Casper | Picqer (e-commerce warehouse management software)
0 Likes
Shopify Staff
Shopify Staff
15 3 9

Our preference, and the preference of our merchants, is that apps never break in production. We are not going to bless a pattern which would cause this.

 

Also, I would note that maintaining your app does not require you to bump the version on every release. We support each version for a year, so it’s possible to stay on a supported release simply by skipping to the latest version every 9 months. And if that is still too much effort, you can rely on our emails. If your app is expected to break due to a version reaching end-of-life, you will receive an email in advance indicating which app, which migration, and the deadline for migrating.

0 Likes
I understand, but that is just wishful thinking from the provider side and not really how most apps are maintained. Sure, big apps in the App Store will update there app every year, most of the time. But there are a lot of small scripts using the api that will not be touched for years. I think this “we give you a whole year to update” attitude of big software companies is hurting the industry and just unnecessary in most cases.

We see customers setting up scripts and apps and not touching the technical side for years. We see 2014 and 2015 versions of the Stripe API being used all the time and it works fine.

We connect with more then 20 platforms and for a lot of them we do not need to touch the functionality cause it works great as is. But more and more of them are saying “just bump the version every 6 or 12 months please”. That in itself is a lot of work for small teams and will push small teams to drop support for less used integrations. Totally unnecessary, when there is a way to keep a version as long as it works. Or only change the version when you really need to change the API, like Github.

I think the oldest stable version is fine for this purpose. But please keep in mind there are ways versioning with short lifetimes can hurt smaller tools and teams. (Yes, 1 year is short.)

Just my 2 cents. 😀
Casper | Picqer (e-commerce warehouse management software)
0 Likes
Shopify Staff
Shopify Staff
15 3 9

This is a really interesting perspective that’s sparked some good discussions for us internally. As one option that’s been talked about, how would you feel if we simply bumped the default/oldest-stable version a month or so before the actual end-of-life date? So for example `/admin/api/graphql.json` would start pointing to `2019-07`, but `/admin/api/2019-04/graphql.json` would keep working for another month. This would give you a month in which you could “roll back” to the previous version and fix the app.

0 Likes
Shopify Partner
29 0 2

Would `/admin/api/2019-07/graphql.json` still be available too?

 

I just recently submitted app and versioning aspect I wrapped as a config variable so I can test in dev before moving to prod.  So every call to Shopify I wrap version that provided during an app loading. 

 

	ShopifyAPI struct {
			Version string `default:"2019-07" envconfig:"SHOPIFY_API_VERSION"`
		}

 

I thought this approach would work since I do not have many apps and bumping version should be fine to handle. 

 

 

 

 

0 Likes
Shopify Staff
Shopify Staff
15 3 9

Yes, it would make sense for `/admin/api/2019-07/` to still be available since that version would still be supported. This is all still a hypothetical of course.

 

Putting the version in a config variable so that you can bump it easily and do tests against different versions in different environments is a great approach.

1 Like
Shopify Partner
17 0 2

So can we assume that the regular unversioned storefront API endpoint: /api/graphql right now will be stable and unchanged until July 1, 2020? (Since Storefront API versioning started in July 1).

 

Is it also assumed that the release candidate version won't have changes vs its stable version?

For example: A dev starts off with 2019-04, they leave it as is until the release candidate for 2020-04 comes out (on Jan, 1, 2020), they would just start migrating, and push it to production before April 1, 2020 (when their current version (2019-04) becomes (2019-07)). This is ideal as long as the release candidate of 2020-04 they started using to migrate with doesn't have any changes with the stable release of 2020-04. Though this doesn't seem to be recommended as it says here https://help.shopify.com/en/api/versioning#the-api-version-release-schedule that release candidates shouldn't be used in production, so does that mean we're really updating every 9 months (On January 1, 2020 - instead of starting migration from 2019-04 to 2020-04, we would start migration from 2019-04 to 2020-01 instead)?

 

Screen Shot 2019-07-21 at 3.26.08 PM.png

1 Like
Highlighted
Community Manager
Community Manager
618 45 81

Hey @andrenaught,

 

You're correct about the Storefront API. The current version (2019-07) will be supported until the 2020-07 version is released.

 

As you mentioned, the release candidate (RC) should not be used in production. In your example, I'd recommend taking one of two paths.

 

1. Start migrating using RC, but keep that development for when the stable version is released. Once something is added to RC the idea is that it will not be changed. We advise against using it in production due to the fact that things are being added to it on an on-going basis. You should be fine to use it when developing with the intention of pushing to production on the stable release.

 

2. Migrate using the previous stable version.

 

I hope that offers some context. Let me know if you have further questions or concerns.

 

Cheers,

1 Like