i dont think a breaking change is necessary, we can generate the url and secure_url as the cloudinary resource requests return giving the option dependent on what they want to use.

it looks like the URLs generated when requesting the resource return the secure_distribution value on both the url and secure URL with the http/https as expected

one thing however that if ound though is cloudinary.url works slightly differently in that it won't just simply return the URL with the cname/secure distribution since those are configured based on the secure value. as this isn't existing functionality and future iterations may change, im not going to try to mess with that and leave the URL generation based on secure:false + cname and secure:true + secure_distribution

another thing, i dont know what the specifics are of this, but i noticed that we weren't updating these values in cloudinaryData and that object is intended to be the best practice path for accessing the node data, so adding the url and secure url override there as well

finally i think theres a bug, i dont think the responsive images are getting the appropriate URL?

if not im not sure where else it would grab a res.cloudinary.com URL from. but im digging into this now

Great catch @colbyfayock, something messed these concepts up in my brain.

🎉 This PR is included in version 0.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀