Using multiple versions of AWS SDK for PHP in single application

[ashishtilara]

Hi,

I am working on a environment which requires to use multiple version of Aws SDK for PHP starting from v1.4.4 and onwards. Basically, we have a large code-base, and it's impractical for us to move everything over to the new API version all at once.

Now, As past v2.0 don't have name space, I am not sure how would I fix this in them but from v2.0 and onwards will have namespaces but they all will be same (eg. v2.0 > Aws\Common\Aws and v2.0.2 > Aws\Common\Aws). Is there anyway I can use both at the same time. Can Amazon try and make namespace structure like Aws\v2_0\Common\Aws, and Aws\v2_0_2\Common\Aws, or any other mechanism that allows multiple versions of same Aws classes can be used at the same time.

https://forums.aws.amazon.com/thread.jspa?threadID=109145&tstart=0

Thanks in advance.
Ashish

[mtdowling]

You can use both SDK1 and SDK2 in the same application without any conflicts. SDK1 does not use namespaces, so the namespaces in SDK2 will never cause a conflict. We have a detailed guide that can help walk you through installing both SDKs and using them side by side in the same application: http://docs.amazonwebservices.com/awssdkdocsphp2/latest/sidebysideguide/sdk-php2-welcome-side-by-side-guide.html. This should help you take advantage of the features in the new SDK while still allowing you to use the old version of the SDK until you are able to migrate your application.

[ashishtilara]

Thanks for the prompt reply.

However, what happens in 6 months time when some of my code uses 1.4, some of it uses 2.0, and some of it uses 2.2? Or in a years time when some is using 3.0?

You can't (and shouldn't) have to guarantee perfect backwards-compatibility between all future versions.

What strategy should I use for using SDKs 2.0, 2.1, 2.2, 3.0, 3.1, etc all in the same PHP context side-by-side? Is there anything that can be done upstream (by you) to help?

[skyzyx]

However, what happens in 6 months time when some of my code uses 1.4, some of it uses 2.0, and some of it uses 2.2? Or in a years time when some is using 3.0?

You can't (and shouldn't) have to guarantee perfect backwards-compatibility between all future versions.

The SDK should be viewed as a complete set by itself. Once SDK 2.x has complete support for all services, you should plan to migrate fully, and all of the 2.x code in your project should all come from the same version of the SDK.

SDK 1.x started life in 2005 as a third-party open-source project called Tarzan. That codebase lasted for 7 years, and we expect that the code that we've recently shipped should last us another several years — even if we eventually version it as 3.0, 4.0, etc.

The reason why this particular change is so impactful is because of the changes that occurred in the PHP language when 5.3 came out. Switching to namespaces forced us to break everything. From the changes we've seen in 5.4 and in previews of 5.5, we don't see changes of this magnitude having to happen again for a long time.

What strategy should I use for using SDKs 2.0, 2.1, 2.2, 3.0, 3.1, etc all in the same PHP context side-by-side? Is there anything that can be done upstream (by you) to help?

You shouldn't. Any SDK code that you use should all be the same version of 1.x or all the same version of 2.x (and possibly 3.x and 4.x). Again, it took us 7 years before we had to go back and do a ground-up rewrite of the code.

Instead of thinking in terms of version numbers, think in terms of generations.

First Generation:

• Tarzan 1.0 (2005)
• Tarzan 1.1 (2005)
• Tarzan 2.0 (2008)
• CloudFusion 2.5 (2010; renamed)
• AWS SDK for PHP 1.0 (2010; renamed; formerly CloudFusion 3.0)
• ...
• AWS SDK for PHP 1.5.15 (2012; equivalent to CloudFusion 3.5.15)

Second Generation:

• AWS SDK for PHP 2.0 (2012; equivalent to Guzzle-based SDK for AWS 1.0)
• ...

We currently provide compatibility for jumping between generations of SDK. You should use all the same version of one generation alongside all the same version of the other generation. Even though this appears to be a jump from 1.x to 2.x, you shouldn't necessarily expect the same kinds of changes from our eventual 3.0.

It would be reasonable to suggest that a future 3.0 release might leverage Traits (new in PHP 5.4; not compatible with 5.3). In this case, some changes might be required, but we anticipate them being adjustments to the existing SDK 2.0 API, instead of being a wholesale rewrite that we're presently experiencing with the move from the older Tarzan/CloudFusion codebase to the new Guzzle-based codebase.

Any time we've been forced to release a breaking change, we've made it a point to call it out very specifically in our release notes, change log, API reference documentation, and other update-related documentation. On the off-chance that a minor breaking change has to be made, we will continue to thoroughly document those changes in the places that we think people will look (it's always a good idea to read release notes before upgrading, but we know that some customers don't).

If you're using Composer to install either SDK (definitely a best practice, and the de-facto successor to PEAR/Pyrus), it would be wise to scope updates down to minor releases (e.g., 1.5., 2.0.) to make sure that you don't jump up to a new major version (e.g., 1., 2.) without knowing it (whereas I'm defining version numbers as <architecture>.<major>.<minor>, like the Linux kernel, Mac OS X, and Firefox releases before 4.0).

Make sense? :)

[ashishtilara]

@skyzyx Pardon my frustration, but this doesn't really answer my concerns. We have a massive code base, and it is literally impractical for us to move wholesale to a new library version every time you push out an update. We will likely always have classes that use 1.4, others using 1.5 and now potentially new classes using 2.0, and these classes all need to be able to used together. We don't have the resources or the risk-appetite to update everything all at once.

Even though you say you don't anticipate future breaking changes, you can never guarantee that, so we are stuck in a predicament. If there will never be upstream support for use-cases such as ours, then we will just have to figure something out ourselves. Thanks for your input.

[jeremeamia]

@ashishtilara I'm not sure I fully understand your use case. We've never had anyone come to us that required dependencies on a full gamut of different versions of the SDK within the same codebase. I'd like to better understand what the problem actually is and what solutions you might have in mind. You had mentioned including the version in the namespace, but I have not seen any other libraries that are doing this, and it also is not really compatible with PSR-0. Are their any other libraries that you consume that allow you to run multiple versions in the same codebase? I'd be willing to look at those for ideas, but I'm not personally aware of any other libraries out there that support the type of behavior you are asking for. I really would like to see what we can do to help you, but I'm not sure if there is bulletproof solution that is beneficial to everyone else, that doesn't involve you having to do some refactoring at some point.