Proposal to merge images/nginx-1.25 into images/nginx and remove redundancy

[blaisewang]

First off, I'd like to extend my congratulations on the release of Ingress NGINX v1.10.0. It's a significant milestone, and I appreciate all the hard work that has gone into making this release possible.

However, I've encountered a concern regarding the recent directory structure change introduced in PR #10629, which added a new folder images/nginx-1.25. Traditionally, nginx version upgrades were managed within the existing nginx.sh script without the need for separate versioned directories. This approach was straightforward and didn't disrupt our internal CI/CD processes.

Given this, I'd like to propose merging the changes from images/nginx-1.25 back into the images/nginx directory and removing the images/nginx-1.25 directory. This change would align with the previous methodology of handling nginx builds and help maintain compatibility with existing CI/CD pipelines that depend on the images/nginx path.

I believe this approach could benefit other users who might face similar issues and help streamline the CI/CD process for projects that rely on Ingress NGINX.

[longwuyuan]

The project supports controller with v1.25 and also another series with v1.21

[blaisewang]

The project supports controller with v1.25 and also another series with v1.21

Thank you for your response. I would like to know if there are any documents or records indicating that starting from v1.10.0, the project plans to support multiple Nginx versions. This information would be greatly helpful for understanding the new direction and adjusting our internal processes accordingly.

[longwuyuan]

Its implied because project will support v1.9.x

[blaisewang]

Its implied because project will support v1.9.x

Just to clarify, do you mean that even after the release of v1.10.0, there will still be a v1.19.7 released that is based on Nginx 1.21.x? I'm trying to understand the versioning strategy and how these parallel releases align with each other.

[longwuyuan]

Its driver by absolute practical requirement first.
And then the circumstances and feedback influence decisions.

For example all users can not be forced to move to v1.10.x so a future fix may well result into a v1.9.7.

For example, once a v1.11.X is out, the project will have option to evaluate stopping support for v1.9.X .

The already published bits will continue to be available for download though (just to state the obvious).

Relevance being your proposal could be feasible in future after v1.11 or v1.12 is out. (if it improves the project for tons of users)

[blaisewang]

Thank you for your explanation. While I understand the release strategy, I believe it might be more logical to maintain the same directory structure and use branches release-1.9 and release-1.10 to track the releases of different versions separately. This approach could potentially simplify the project structure and make it easier for users to follow and integrate with their existing workflows.

[strongjz]

/assign @rikatz

I agree this should be cleaned up. We can bump it directly on the 1.9 branch if we need to rebuild nginx.

[strongjz]

/priority backlog
/triage accepted

[blaisewang]

@strongjz Thank you for accepting the proposal. If it's possible, I would be glad to take the cleanup work.

[strongjz]

While we support both 1.9 and 1.10, which use 1.21 and 1.25, we need to keep both directories for the time being. It will be cleaned up in the future.

/close

[k8s-ci-robot]

@strongjz: Closing this issue.

In response to this:

While we support both 1.9 and 1.10, which use 1.21 and 1.25, we need to keep both directories for the time being. It will be cleaned up in the future.

/close

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/test-infra repository.