Upgrading from Spring Boot 1.x section

[snicoll]

The amount of changes between 1.x and 2 are important and it is expected we'll get a lot of users asking questions when they upgrade (it is already happening with early adopters and maintainers of downstream spring modules).

We usually have the release notes covering the upgrades aspect but I am wondering if we shouldn't try something a bit more structured for 2.0. Release notes are single page and can be a bit overwhelming (I expect the one on 2.0 to be!).

This issue is meant to gather feedback and plan future actions.

[philwebb]

I'd still prefer to keep history out of the user guide if at all possible. Would a dedicated wiki page work?

[snicoll]

A dedicated wiki page is what the release notes are today so I don't believe it does otherwise I wouldn't have created the issue :) I am with you it shouldn't be in the user guide.

The main goal here is that I think we should be a bit more thorough as the changes can be more intrusive. I think a set of dedicated pages on the wiki should work but it's really about us taking the time to analyse and describe what has changed.

[wilkinsona]

A separate wiki page sounds good to me

[ryonday]

I ran into difficulties trying to migrate a Spring Boot 1.3.8 app to 2.0 because entire swaths of the Actuator code base have been deleted due to the switch to Micrometer including classes that were prescribed for direct use such as CounterService and GaugeService.

It's not immediately apparent from documentation what the migration path is here, and perhaps the Micrometer folks would consider supporting some of the old Actuator classes in their micrometer-spring-legacy project so that there is at least a drop-in to keep older applications chugging along.

[gregturn]

Things I'd suggest including in such a guide.

• Metrics - since the whole face of metrics is changed (usage, customized, health, URIs), we should provide some sort of matrix showing "if you used CounterService, switch to ...". Additionally, show HOW to enable metrics, since they are now disabled unless you put in a certain property. I would certainly illustrate memory-based as well as at least Redis.
• Spring Security's default posture - with the overhaul of Spring Security's default position, I would favor showing what it does NOW when added to classpath, simple options to change the password, and best plan to plugin a custom policy.
• Security/Actuator - Previous point bleeds into this. May need a point-by-point listing of what the old actuator endpoints where, and how they've changed with/without Spring Security on the classpath, and how to tune sensitivity.
• Document that /health has been replaced with something else. Show the new path, and optionally show how to customize a Boot HealthIndicator to point at the old path?
• Illustrate that 1.x had JMX and Web-based endpoints on by default, but in 2.x, you must enable one, the other, or both.

I don't know where, @dsyer / @spencergibb , but I feel as if there needs to be a counterpart to this document over in Spring Cloud to go along with Finchley (or Edgware)? Stuff like the updated starter names, etc. would fit nicely in an "Upgrading my Spring Cloud app" document.

[philwebb]

Thanks @gregturn. We can use this wiki page for the content.

[snicoll]

I think the migration guide is in decent shape now.