Reorganize the release templates so they fit the actual required information

[jacobdotcosta]

Several changes are required to the release files:

Product

The requests to product teams should first request for the product information:

e.g.

===
* product name: [ replace by associated product name e.g. JWS ]
* product version: [ replace by associated project version e.g. 5.3.1 ]
* end of support: [ replace by end of support date in yyyy-mm-dd format ]

After that should come the artifact list

artifact name: [ replace by associated artifact name e.g. hibernate ]
artifact version: [ replace by artifact version e.g. 5.3.1 ]
supported version: [ replace by appropriate -redhat version ]

NOTE: In the previous section we could probably skip the artifact name.

The paragraphs requesting the information should be replaced in order to ask for the supported product and artifact versions.

Some of our artifacts depend on your product and we need to know which product version we should be using for this new
release.

While we don't require a new release of your product as long as the artifacts you provide us with are tested and supported
on Spring Boot 2.4.3, it's important that you let us know until when your product is supported so that we can plan
future releases accordingly. For reference, we will support this new release until 31 Aug 2022.

Should be replaced by something like.

Some of our artifacts depend on your product and we need to know which product version we should be using for this new
release. It's important that you let us know until when your product is supported so that we can plan
future releases accordingly. For reference, we will support this new release until EOL.

Artifacts

Artifacts released by other teams must request both the -redhat version and the upstream version of those artifacts as well as it's EOL.

Starters released by other teams

Starters released by other teams must request both the -redhat version as well as the upstream version. Must also request them to be tested.

Starters coded by other teams and released by ourselves

Starters released by other teams must request the upstream version that is tested against the version we're releasing.

Starters coded and released by ourselves

Mustn't necessarily be different than the ones released by other teams

All Of The Above

In all the component/starter list we should include int the reference to the upstream version something stating where it comes from.

[cmoulliard]

Should be replaced by something like.

Remember what we discussed this morning during the meeting as we have 2 use cases:

• Not releasing a starter: In this case, the text of the paragraph should not include the fact that they have to test by example Hibernate-Core against SB 2.x as this is the job of the QE SB engineer
• Releasing a starter: Mention about test is important as they could either just re-test their current starter according to the next version of the starter OR create a new starter to bump their version to use the new SB 2.x version

@jacobdotcosta @aureamunoz @metacosm

[jacobdotcosta]

Yes, but while writing I see we could have more use cases. Maybe they'll merge but we could have some differences ther.

[cmoulliard]

The requests to product teams should first request for the product information:

e.g.

===
* product name: [ replace by associated product name e.g. JWS ]
* product version: [ replace by associated project version e.g. 5.3.1 ]
* end of support: [ replace by end of support date in yyyy-mm-dd format ]

After that should come the artifact list

If the description includes first a section to request : product version, EOL, ... what will then happen if we dont have a relation 1 to Many between the product and artifacts but m to m ? Does the relation m to m exist when we populate a jira issue for a stakeholdr ?

@jacobdotcosta @aureamunoz

[jacobdotcosta]

What do you mean m:n? I don't think 1 component/artifact version can come from different teams.

The special case we have with Narayana is that EAP provides the supported version whereas we're asking JBTM for the upstream version In this case we code the starter. Maybe, instead of asking JBTM for the upstream version to use on our starter we should use the upstream version that EAP used on their release.

[cmoulliard]

What do you mean m:n?

What I say is "Can we create a JIRA ticket assigned to a project EAP, JWS, ... where some of the GAVs listed part of the description are maintained under different product/version ? If this is the case then you will have a m sections of product name, version, EOL and n sections covering the GAVS but in this case how will it be possible to match the product releasing a GAV ?

[jacobdotcosta]

I'm not sure this is a use case since the starting point of the information they provide is the product version.

IMHO we shouldn't mix GAV from different product versions since they test the product as a whole and we'd loose that stability/benefit.

[jacobdotcosta]

Discussing the case of the Narayana and Vert.X starters, @gytis suggested that the upstream would be the most up-to-date version and only ask for the productized version.