Allow developers to receive stack updates with no changes to existing projects

[neeraj-laad]

Most of our stack do this already. However all java stacks (spring-boot2, Microprofile and spring-boot2-liberty) have this issue. Perhaps quarkus and vertx might need to be checked too.

There are 2 fundamental issues here..

1. Template project definition (child pom in case of maven) refers to a specific parent definition (parent pom in case of maven).

2. Parent project definition versions are aligned to stack versions today even if the project itself might not have changed.

This reason behind aligning them was to provide clarity to the developer with respect of what stack they are running with etc. However, I fee this is causing more pain than we imagined and needs to be revisited. Currently this causes more work for both the stack providers and application developers.

1. Stack providers have to ensure and edit multiple files (stack.yaml, parent pom child pom) while updating a minor change in the stack.

2. Developers who have a working project can be left broken when a new stack version is released. This could really put them off.

A more transparent mechanism that honours and pulls more compatible changes would be needed. We will of course need to ensure we follow appropriate semantic versioning while updating stacks so users never get changes that would break their existing projects.

[neeraj-laad]

I would like to do both:

• Do not mandate that pom version need to match stack version (helps stack providers)
• Allow version range in child pom ( helps application developers)

@ebullient @BarDweller @gcharters @Emily-Jiang @seabaylea @chilanti @kylegc

I would like to get your thoughts on this..

[ykoyfman]

@neeraj-laad Would any of the changes you're proposing change the behavior of appsody always pulling the latest stack image?

[seabaylea]

Hi @ykoyfman. This won't change the behaviour that appsody will check that you're using the latest version of the stack that you're configured to use (via the .appsody-config.yaml file).

[ebullient]

The “edit lots of files” problem has a different solution as you know (using the stack image to build the template). I am splitting #300 into pieces, starting with #325 to bring the stack.yaml into image versioning, etc. The stack can change behavior, and the pom is where fixes go, and is where traceability comes from.

Adding the version range to the parent pom is covered by #229. The Spring stack does this already, and @BarDweller has changes for other java stacks in flight.

There will be potentially breaking changes... these could be introduced by the stack in the pipeline (as happens now) leading to mysterious failures. Better error messages and better semantic versioning will help.. as will the 1.x release of any of these stacks... we’re still learning, which will mean some churn.

[neeraj-laad]

I think we all agree the child projects should allow a range of parent version to work with..

I'm more keen to know if any of you believe we should break the coupling between stack version and parent pom version, as that decreases the number of times the poms can go out of sync when new versions arrive.

[skoh7645]

As of yet, we have the version ranges for the following stacks:

• java-spring-boot2
• java-spring-boot2-liberty
• java-microprofile
• vertx
• quarkus (works on appsody run but not on appsody build)

[neeraj-laad]

Created a separate issue for remaining quarkus work #389. Closing this epic.