Use latest Java Spring Boot stack as default

[apupier]

it was set to a previous version originally to use a schema version 2.1 but in fact the default version was already upgraded to 2.2 3 months ago db0c583

What does this PR do?:

Summarize the changes. Are any stacks or samples added or updated?

Which issue(s) this PR fixes:

Link to github issue(s)

PR acceptance criteria:

• Contributing guide
  Have you read the devfile registry contributing guide and followed its instructions?
• Test automation
  Does this repository's tests pass with your changes?
• Documentation
  Does any documentation need to be updated with your changes?
• Check Tools Provider
  Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)

How to test changes / Special notes to the reviewer:

[openshift-ci]

Hi @apupier. Thanks for your PR.

I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[thepetk]

I think here the separation between 1.x and 2.x stacks work differently. It's not necessary that the 1.x stacks will use the 2.1.x devfile schema only and so on.

Actually the 1.x stacks are using innerloop-only commands, while the 2.x stacks have innerloop+outerloop commands (https://devfile.io/docs/2.2.0/innerloop-vs-outerloop).

As some of the stack consumers use the current default, I'm not sure about the impact that this change might have. I'd suggest keeping the default as is, as it already uses the 2.2.x devfile schema version.

WDYT?

[apupier]

the default was set to the 1.x because of the limitation to schema version. Per comments on the commit, it is because not everything was ready for schema version 2.2 BUT 3 months ago, the latest 1.x and the default has been upgraded to use schema version 2.2. So either, there is still this limitation and we should switch back to schema version 2.1 on the 1.4.0 stack OR the limitation does not exist anymore and it sounds benefitials to move to latest 2.x stack which has a lot more pre-configured.

But in terms of impact, I do not know exactly, last time I played with that was several years ago so my knowledge is quite outdated.

[apupier]

new argument to set default to new version. i tried with a recent Camel on Spring Boot application and it is working with 2.2.0 stack but not the 1.4.0. With 1.4.0, on changes, it is trying to indefintely restart the application and it is not picking changes

[thepetk]

the default was set to the 1.x because of the limitation to schema version. Per comments on the commit, it is because not everything was ready for schema version 2.2 BUT 3 months ago, the latest 1.x and the default has been upgraded to use schema version 2.2. So either, there is still this limitation and we should switch back to schema version 2.1 on the 1.4.0 stack OR the limitation does not exist anymore and it sounds benefitials to move to latest 2.x stack which has a lot more pre-configured.

But in terms of impact, I do not know exactly, last time I played with that was several years ago so my knowledge is quite outdated.

I don't think this is the case anymore for the limitation tbh, so I'd say the 1.x can stay at the 2.2.x version. After latest changes many of the 1.x stack versions have already adopted these versions.

TBH I'm also in favor of adopting/improving the versioning of the stacks. Moving the default to the latest could be a good way to go. Although atm I'm not sure about the consumers and how this might affect them. For example we have devfile/api#1524 opened.

I would like to open a spike issue, so we can investigate first potential impact with our major consumers before merging this PR.

[thepetk]

the default was set to the 1.x because of the limitation to schema version. Per comments on the commit, it is because not everything was ready for schema version 2.2 BUT 3 months ago, the latest 1.x and the default has been upgraded to use schema version 2.2. So either, there is still this limitation and we should switch back to schema version 2.1 on the 1.4.0 stack OR the limitation does not exist anymore and it sounds benefitials to move to latest 2.x stack which has a lot more pre-configured.
But in terms of impact, I do not know exactly, last time I played with that was several years ago so my knowledge is quite outdated.

I don't think this is the case anymore for the limitation tbh, so I'd say the 1.x can stay at the 2.2.x version. After latest changes many of the 1.x stack versions have already adopted these versions.

TBH I'm also in favor of adopting/improving the versioning of the stacks. Moving the default to the latest could be a good way to go. Although atm I'm not sure about the consumers and how this might affect them. For example we have devfile/api#1524 opened.

I would like to open a spike issue, so we can investigate first potential impact with our major consumers before merging this PR.

@apupier after an investigation, I think there should be no problem to adopt the 2.2.0 java-springboot stack version as the default.

The PR needs approval from @devfile/che-team & the stack owner (@kadel )

[apupier]

The PR needs approval from @devfile/che-team & the stack owner (@kadel )

bump @kadel

[svor]

LGTM

I see warning message: git is not installed, but it's not related to the current PR:
Git not found. Install it or configure it using the "git.path" setting.

All commands work as expected

[thepetk]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apupier, kadel, svor, thepetk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [thepetk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment