Yes, 1.0.0 to 1.1.0 does require a migration (specifically, for the new tagging feature) as mentioned in the above upgrade path.
However in the future, please do not assume whether a particular upgrade path needs migrations or not solely based on the version number. One of the goals of the new migrations framework is to allow us to introduce migrations in any release. The fact that we only introduced migrations in “major” release pre 1.0 was an old internal decision taken due to the lack of robustness of the previous migrations framework.
The new framework is still awaiting for a complete documentation section, but the gist of it is that one should take advantage of the kong migrations list command in order to determine whether migrations should be run or not. The -q option (quiet) along with the exit codes of that command allow for scripting the deployment workflow of a new Kong version:
- download version x.y.z
- test
kong migrations list -q- does it require running migrations? (this command also considers plugins, so it can also be run when installing or upgrading plugins and determine whether those need migrations or not) - if so (exit code 5), then
kong migrations up(runs with a cluster mutex, so no worries if several new nodes run this in parallel) - start new nodes
- de-commission previous nodes
- do the new nodes need to finish their 2 step migrations?
kong migrations list -qagain - if so (exit code 4), then
kong migrations finish
The new migrations framework introduced in 1.0 allows for much smoother upgrades (with clear upgrade paths from our side, better scriptability, better re-entrancy, etc… read more in the PR https://github.com/Kong/kong/pull/3802), and in the future, we may introduce migrations in both major and minor releases, and we’ve considered doing so in patch releases as well if necessary (depending on the migration itself and the state of the framework by then, as it still needs some work and production mileage as of today).