Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use latest Java Spring Boot stack as default #439

Merged
merged 1 commit into from
Jul 23, 2024

Conversation

apupier
Copy link
Contributor

@apupier apupier commented Jul 4, 2024

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:

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
devfile@db0c583

Signed-off-by: Aurélien Pupier <apupier@redhat.com>
@apupier apupier requested review from kadel and a team as code owners July 4, 2024 10:58
@openshift-ci openshift-ci bot requested review from elsony and Jdubrick July 4, 2024 10:58
Copy link

openshift-ci bot commented Jul 4, 2024

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.

Copy link
Contributor

@thepetk thepetk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

apupier commented Jul 4, 2024

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
Copy link
Contributor Author

apupier commented Jul 4, 2024

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
Copy link
Contributor

thepetk commented Jul 4, 2024

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
Copy link
Contributor

thepetk commented Jul 5, 2024

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
Copy link
Contributor Author

apupier commented Jul 23, 2024

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

bump @kadel

@openshift-ci openshift-ci bot added the lgtm Looks good to me label Jul 23, 2024
Copy link
Collaborator

@svor svor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

screenshot-nimbusweb me-2024 07 23-13_03_20

Copy link
Contributor

@thepetk thepetk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Copy link

openshift-ci bot commented Jul 23, 2024

[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:

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

@thepetk thepetk merged commit 0513d06 into devfile:main Jul 23, 2024
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants