Allow a DB tenant to manually select the version of RavenDb they wish to target

Justin Adler

July 13, 2012 00:14

None

For each tenant / instance of a RavenDb hosted @ RavenHQ, the version is automatically updated a few weeks after a new stable is out.

Maybe allow the option for each person to

a) Autoupgrade to the most recent stable, when you guys roll that out

b) Do not autoupgrade and allow the user to define which version of ravendb they wish to target .. meaning they might not want to upgrade .. or upgrade when they are ready on their own time schedule.

Date Votes

2 comments

0
Jonathan Matheus July 18, 2012 16:35
We are putting a lot of thought into a better upgrade workflow. We're aiming to be more transparent and informative about the timeline and implications of an upgrade. We do our best to work with the RavenDB team to ensure that server upgrades are back-compatible with previous clients.

For your suggestions:

a) Autoupgrade to the most recent stable, when you guys roll that out

This is the workflow that we have now. However, we plan to provide a mechanism to communicate supported clients and changes that might affect databases server-side (like indexes).

b) Do not autoupgrade and allow the user to define which version of ravendb they wish to target .. meaning they might not want to upgrade .. or upgrade when they are ready on their own time schedule.

I don't believe that we'll be able to cover a scenario where users get to pick the version of RavenDB they want to run. The issue here is that it wouldn't be economically feasible to host servers for each version of RavenDB. Would the following workflow meet your needs:
- RavenHQ will support the 2 latest stable versions
- Users can choose to get on a slower upgrade path (usually every 3 months)
- These users can choose to upgrade to the latest version off-cycle, but it might require a connection string change.
Comment actions Permalink
0
Justin Adler July 23, 2012 01:32
Hi Jonathan,

I really like the following comments you suggested:
- RavenHQ will support the 2 latest stable versions
^^ that allows us to determine when -we- wish to roll out to the latest version
- Users can choose to get on a slower upgrade path (usually every 3 months)
^^ So if we want to, we have a few months (for example) to check our code, etc... and tell our code to use the latest version, on our own terms / date (within that 'window')
These users can choose to upgrade to the latest version off-cycle, but it might require a connection string change.

^ Brilliant!

Lastly, would also be great to allow users to upgrade to the most recent version SOONER also. Like right now, there (has been) very little info with regards to when the latest stables will be pushed up to RavenHQ. Mind you, the number of 'stables' has also slowed right down .. which I'm sure is linked to the fact that RavenHQ now exists (and how you guys need to upgrade, etc). So it would be nice to offer the ability to upgrade more or less asap when a new stable comes available.

Sorta like this.

Current DB: v960.

New Stable: v1.2

When 1.2 is released, everyone still is auto-default targeting v960. Clients can manually -opt- to target v1.2 if they wish (aka. Early adopters). New Db's that are made are targeting v960.

Now, after a few months, all existing clients will target v1.2. People will have to -opt- to target v960.

Fast forward to a new stable .. lets call it v1.3

v1.3 is released.

v960 is archived. No one can access that anymore.

v1.2 is the 'default' connection (which occured, above)

v1.3 is available for early adopters.

After a few months, the default is moved to v1.3 and v1.2 is available still.

rinse, repeat.

Using the connection string could handle this. Eg. version = "default|version-number"
eg

<add name="RavenDB" connectionString="Url=http://localhost:8080" version="default" />
<add name="RavenDB" connectionString="Url=http://localhost:8080" version="1.2"/>
Comment actions Permalink

Please sign in to leave a comment.