Upgrading gemfire version to 8.2 - #251
Conversation
|
Hey sbawaska! Thanks for submitting this pull request! All pull request authors must have a Contributor License Agreement (CLA) on-file with us. Please sign the appropriate CLA (individual or corporate). When sending signed CLA please provide your github username in case of individual CLA or the list of github usernames that can make pull requests on behalf of your organization. If you are confident that you're covered under a Corporate CLA, please make sure you've publicized your membership in the appropriate Github Org, per these instructions. |
|
Hi, Thanks for the contribution, can you sign the CLA and I will merge it in. It looks like you work for Pivotal though so if you are in any of the Pivotal Orgs you should just be able to make your membership public and be approved automatically. |
|
I have made my "pivotal-cf" membership public. |
|
@cgfrost Should we actually slacken this restriction to |
|
The problem with that is if the build-pack picks up a GemFire release, before the service team. Since GemFire servers are backwards compatible, an old client in the buildpack will be able to talk to a new server, but if the buildpack picks up a new client, it won't be able to talk to an old server. |
|
But that's true now as we upgrade to 8.2 as well. There's no way to guarantee that any user will have upgraded when the buildpack does. Until the client is backwards compatible, there's no real way to solve this problem. In lieu of a solution, we go for consistency which is latest possible version at all times. |
Upgraded to latest GemFire release to be used for session caching.