Provide a dependency management and dependency upgrade guide

[wilkinsona]

I'm not 100% sure that a guide is the right place for this, but I think it warrants some discussion and a guide feels a better fit than reference documentation. It relates to this Spring Boot issue and this answer on Stack Overflow by @olivergierke.

A guide could help beginners with Maven and Gradle dependency management, explaining how to upgrade to new versions of Boot (and perhaps Cloud as well), and how to override the versions of individual dependencies.

[gregturn]

Since this information t nds to be build tool specific do you think augmenting gs-maven and gs-gradle make sense?

[wilkinsona]

Good question. The mechanics of how to upgrade or to override a version are definitely specific to Maven or Gradle. General content about why you might want to upgrade or override a version is more generally applicable. I guess it depends if that is content that we feel is an appropriate topic for a guide.

[gregturn]

We could also fit it into a understanding document and have both the maven and the grade guide link to it if you think that's a better prospect.

[dsyer]

I think it is likely to be longer than an "understanding" piece. Topical guide with links to gs-maven/gradle? There's some material in that blog I write a while back as well (https://github.com/dsyer/dependency-hell).

[gregturn]

I was going to mention topical guide next.

[gregturn]

In light of @buzzardo 'a recent linking efforts we should cross link this info in several places

• grade and maven guides
• gs-spring-boot for sure
• possibly augment either the header mentioning each build tool?

[dsyer]

Topical guides have their own lifecycle (unlike understanding guides), and their own issue tracker. I can see the advantage for something chunky like this.

[Buzzardo]

Thank you, Greg. That's definitely part of my agenda. Thank you to you, too, Dave. Chunking is another part of my strategy.

The overall ideas are to increase discoverability by linking whenever possible (within the bounds of reason) and creating a situation where we can use the same piece of content more than once (via chunking).

J

On Mon, Sep 11, 2017 at 8:42 AM, Dave Syer notifications@github.com wrote:

Topical guides have their own lifecycle (unlike understanding guides), and their own issue tracker. I can see the advantage for something chunky like this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spring-guides/getting-started-guides/issues/52#issuecomment-328532789, or mute the thread https://github.com/notifications/unsubscribe-auth/AE-6ytDrsgo97b9grovAMQIx7oxn8UiCks5shTjLgaJpZM4PS3eW .

[gregturn]

I'd call it something like topical-upgrading-spring, so it clearly shows the problem it solves, and we understand this topical guide extends across the portfolio (at least it should in my opinion).

We could shoot for:

• Spring Framework
• Spring Boot
• Spring Data
• Spring Cloud
• Reactor

These are the big ones in my book we should cover.

[dsyer]

IMO we should only cover Framework, Data and Reactor as examples of dependencies managed by Spring Boot. We need to guide users to the safest stable path, which is Spring Boot dependency management. It will just confuse everybody if we start listing 4 different ways to do something.

[wilkinsona]

Given the Boot basis of all(?) the other guides, I'd prune that list to:

• Spring Boot
• Spring Cloud

I think everything else should be tackled as a discussion of overriding a dependency version that's provided by the Boot or Cloud dependency management. That's large the same for first- and third-party projects, although I'd expect the overriding of third-party project versions to be more frequent than for first-party projects.

[wilkinsona]

I'd go for a name other than topical-upgrading-spring too. The topic is more than upgrading. IMO it's dependency management, what you get from Boot and Cloud, what happens when you upgrade Boot or Cloud, and how you stray safely from the golden path provided by Boot and Cloud.

[gregturn]

I understand dropping Reactor from that list and Spring Framework, since they'll be managed by Boot, but given the perspective of @olivergierke 's SO answer, why cut Spring Data from the list? It sounds highly relevant and its #3 "project" for end users. Are we that swift in making maintenance releases with Boot to match maintenance releases for Spring Data?

[wilkinsona]

Are we that swift in making maintenance releases with Boot to match maintenance releases for Spring Data?

Yes. For example, Ingalls SR7 released today and Boot 1.5.7 is planned for tomorrow.

A more interesting case is using a whole different Data release train with Boot. However, that needs to be done carefully as with any other dependency override as there's no guarantee of compatibility. That's why, IMO, it needs to be discussed a part of overriding versions rather than as upgrading to a new version of one of our projects.