feat: onboard chiselled tomcat #637
Conversation
vpa1977
requested review from
ROCKsBot,
alesancor1 and
zhijie-yang
as code owners
zhijie-yang
changed the title
- jdk-based rocks will be published in `tomcat-dev` rock and follow development rock specification. - use <version>-<X.Y> version tags for "production" rock
| commit: 59f3f98b37988ab3a07419098e755c892c44f93d | ||
| directory: tomcat/10-jre-21-24.04 | ||
| release: | ||
| 10-21-24.04: |
There was a problem hiding this comment.
IMO the channel is still weird.
Our convention is <swVersion>-<base>_<risk>. In this case, I find it really hard for a user to understand what's actually being delivered. Furthermore, it will make it really hard for things like the store to filter the rock by "version"...because - what is the version??
I ack the challenge though. No perfect, but what about 10jre21-24.04? I'd love to get the store folks opinion on this as well.
There was a problem hiding this comment.
@vpa1977 just checked with the store team, and the preferred approach would be:
10-jre21-24.04 (<swVersion>(-<platform>)-<base>).
One other thing you can do, to preserve an intuitive UX for users, is to still have 10-24.04, which uses the default jre in 24.04, and is the same artifact as 10-jre21-24.04.
There was a problem hiding this comment.
NOTE: This was resolved but not applied
Until we switch to SRUs for tomcat sources, use nil EOL to indicate that the images are essentially pre-release.
Removed nil values for end-of-life in Tomcat releases.
There was a problem hiding this comment.
I'll also let @zhijie-yang and @alesancor1 handle the CI failure
|
Closing PR - tomcat is an universe package and will be provided as a pro rock. |
2 participants
Ping the @canonical/rocks team.
Description
This PR onboards chiselled tomcat images.
Related issues
#638
Picture of a cool rock: