Skip to content

Upgrading gemfire version to 8.2 - #251

Closed
sbawaska wants to merge 1 commit into
cloudfoundry:masterfrom
sbawaska:master
Closed

Upgrading gemfire version to 8.2#251
sbawaska wants to merge 1 commit into
cloudfoundry:masterfrom
sbawaska:master

Conversation

@sbawaska

Copy link
Copy Markdown

Upgraded to latest GemFire release to be used for session caching.

@cfdreddbot

Copy link
Copy Markdown

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.

@cgfrost

cgfrost commented Nov 16, 2015

Copy link
Copy Markdown
Contributor

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.

@sbawaska

Copy link
Copy Markdown
Author

I have made my "pivotal-cf" membership public.

@nebhale

nebhale commented Nov 16, 2015

Copy link
Copy Markdown
Contributor

@cgfrost Should we actually slacken this restriction to 8.+? It seems like you've uploaded a couple of subsequent releases that we not actually picked up by users.

@sbawaska

Copy link
Copy Markdown
Author

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.

@nebhale

nebhale commented Nov 17, 2015

Copy link
Copy Markdown
Contributor

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.

@cgfrost cgfrost closed this in c5eeb77 Nov 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants