Upgrade to Jetty 9.4.31

[joakime]

Note: This PR is based on PR #285 (once that merges, the changes here will be 1 commit, 1 file, 2 lines)

[gregw]

@donmccasland FYI

[gregw]

@donmccasland bump! can you do a release of this?

[donmccasland]

Sure thing.

On Mon, Aug 17, 2020, 5:43 AM Greg Wilkins notifications@github.com wrote:

@donmccasland https://github.com/donmccasland bump! can you do a release of this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GoogleCloudPlatform/jetty-runtime/pull/286#issuecomment-674858333, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF76UWPKKU7W3PRLQU7QIDSBEQWTANCNFSM4POBXJGA .

[joakime]

@donmccasland thanks for the push.

I can see image gcr.io/google-appengine/jetty:9.4-2020-08-19_20_14 is present now. But, why is this not tagged properly?

For a start, it's not labelled as 9 or latest, what is the process for these 2 tags to be updated?

But it should also have the <minor_version> as that is important, where is the 9.4.31 tag?

Reminder, Jetty versioning is <servlet_support>.<major_version>.<minor_version> (which has been the case since 1995). Those users that care about security, will need to know the <minor_version> portion. See https://www.eclipse.org/jetty/security-reports.html

I realize you already have a tag/label scheme in place, but there's really no limit to the number of tags an image may have. The official tag list should also have the 3 parts of the version string at a minimum (the 4th portion is unnecessary, which in the case of an official Jetty 9.4.x release is the timestamp, is only relevant in rare situations of updating old releases for security issues)

[donmccasland]

I'm waiting on a code change review to move the tag.

As for adding another tag. Are you asking for a 9.4.31 tag or a 9.4 tag? Why haven't we needed it previously?

On Mon, Aug 24, 2020 at 4:55 AM Joakim Erdfelt notifications@github.com wrote:

@donmccasland https://github.com/donmccasland thanks for the push.

I can see image gcr.io/google-appengine/jetty:9.4-2020-08-19_20_14 is present now. But, why is this not tagged properly?

For a start, it's not labelled as 9 or latest, what is the process for these 2 tags to be updated?

But it should also have the as that is important, where is the 9.4.31 tag?

Reminder, Jetty versioning is

.. (which has been the case since 1995). Those users that care about security, will need to know the portion. See https://www.eclipse.org/jetty/security-reports.html I realize you already have a tag/label scheme in place, but there's really no limit to the number of tags an image may have. The official tag list should also have the 3 parts of the version string at a minimum (the 4th portion is unnecessary, which in the case of an official Jetty 9.4.x release is the timestamp, is only relevant in rare situations of updating old releases for security issues) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or unsubscribe .

[joakime]

The tag would be "9.4.31", and I feel that this 3 level version (<servlet>.<major>.<minor>) should be kept moving forward.

The tags can be used for multiple purposes, from verifying the version in use, to having reproducible testing scenarios.

Right now, the gcr.io tags for jetty-runtime are too abstract and don't convey the details that users of Docker have come to expect. https://console.cloud.google.com/gcr/images/google-appengine/GLOBAL/jetty

There's really only 2 things you can obtain from that set of tags.

• Servlet 3.1 on Jetty (the tag "9")
• Major release 4 of Jetty 9. (the tags starting with "9.4")

I'm not proposing the nth level of tags that are common on https://hub.docker.com/_/jetty (On hub, the same image can have multiple tags: Example: 9.4.31, 9.4, 9, 9.4.31-jdk8, 9.4-jdk8, 9-jdk8, latest, jdk8)

I do want to see the 3rd part of the version string as a configurable option for FROM lines. The "9.4.31" (and soon "9.4.32") will go a long way to help users using jetty-runtime know when the minor version they are waiting for is now available to use. The only way to know this detail is to either upgrade your image from a black box image reference, or "latest" and then check after deployment. Or to download the image and inspect it's contents before using it. It would be smarter to just include the relevant portions of the version string in the tags, for everyone to benefit.

[donmccasland]

Okay, change has been submitted. Tags should get pushed shortly for the new image as latest,9,9.4,9.4.31 and we'll change our process to add the X.Y.Z tag to every release.

On Mon, Aug 24, 2020 at 4:55 AM Joakim Erdfelt notifications@github.com wrote:

@donmccasland https://github.com/donmccasland thanks for the push.

I can see image gcr.io/google-appengine/jetty:9.4-2020-08-19_20_14 is present now. But, why is this not tagged properly?

For a start, it's not labelled as 9 or latest, what is the process for these 2 tags to be updated?

But it should also have the as that is important, where is the 9.4.31 tag?

Reminder, Jetty versioning is

.. (which has been the case since 1995). Those users that care about security, will need to know the portion. See https://www.eclipse.org/jetty/security-reports.html I realize you already have a tag/label scheme in place, but there's really no limit to the number of tags an image may have. The official tag list should also have the 3 parts of the version string at a minimum (the 4th portion is unnecessary, which in the case of an official Jetty 9.4.x release is the timestamp, is only relevant in rare situations of updating old releases for security issues) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or unsubscribe .