update version to 1.1.0

[shankarseal]

Description

Describe the purpose of and changes within this Pull Request.
Update version to 1.1.

Testing

Do any existing tests cover this change? Are new tests needed?
No new tests needed.

Documentation

Is there any documentation impact for this change?
No.

Installation

Is there any installer impact for this change?
No.

[dthaler]

I don't see any reason to bump the minor version. Why isn't this "update version to 1.0.0"?

[dthaler]

Since there is 1 approval already, but still no answer to my question nor any issue referenced that this would fix, putting request changes so it isn't auto-merged without discussion.

[saxena-anurag]

Since there is 1 approval already, but still no answer to my question nor any issue referenced that this would fix, putting request changes so it isn't auto-merged without discussion.

Hi Dave,

There was an issue (#3669) filed earlier to move to this approach and we have been following this for past few releases. The PR corresponding to the above issue (#3690) did update the guidance in the Release Doc, but I think it is still not very clear and can be updated to make it clearer.

[dthaler]

Since there is 1 approval already, but still no answer to my question nor any issue referenced that this would fix, putting request changes so it isn't auto-merged without discussion.

Hi Dave,

There was an issue (#3669) filed earlier to move to this approach and we have been following this for past few releases. The PR corresponding to the above issue (#3690) did update the guidance in the Release Doc, but I think it is still not very clear and can be updated to make it clearer.

Thanks Anurag that makes sense. What confuses me is that there's no PR to update version to 1.0.0. This PR (for 1.1.0) is fine given your answer but shouldn't be merged until after release, which should happen after merging a PR that updates the version to 1.0.0 (which comes after 1.0.0.rc or whatever).

[saxena-anurag]

Since there is 1 approval already, but still no answer to my question nor any issue referenced that this would fix, putting request changes so it isn't auto-merged without discussion.

Hi Dave,
There was an issue (#3669) filed earlier to move to this approach and we have been following this for past few releases. The PR corresponding to the above issue (#3690) did update the guidance in the Release Doc, but I think it is still not very clear and can be updated to make it clearer.

Thanks Anurag that makes sense. What confuses me is that there's no PR to update version to 1.0.0. This PR (for 1.1.0) is fine given your answer but shouldn't be merged until after release, which should happen after merging a PR that updates the version to 1.0.0 (which comes after 1.0.0.rc or whatever).

Agree that main did not first move to 1.0.0 and directly jumped to 1.1.0. (It was earlier at 0.22 given the last release was 0.21). But now that the release branch has been forked, and it has 1.0.0 version, I think it is safe to merge this PR in main branch to bump version in main to 1.1.0, so that any future PRs in main branch that want to take dependency on the current version in main branch are not blocked (I dont think there actually are any such PRs right now though)

[dthaler]

Agree that main did not first move to 1.0.0 and directly jumped to 1.1.0. (It was earlier at 0.22 given the last release was 0.21). But now that the release branch has been forked, and it has 1.0.0 version, I think it is safe to merge this PR in main branch to bump version in main to 1.1.0, so that any future PRs in main branch that want to take dependency on the current version in main branch are not blocked (I dont think there actually are any such PRs right now though)

I disagree. Main should first move to 1.0.0 rather than skipping versions. What you are describing doesn't follow my interpretation (perhaps yours differs) of docs\ReleaseProcess.md so I guess we should have an issue for that and discuss in triage.

Example: PR #4739 added a file to the release/1.0 branch but not to main. Why should that file not be in main as well? Do we really think it won't be needed for 1.1? Moving main to 1.1 before that file is present would mean that the baseline for 1.x does not include it.

[shankarseal]

interpretation (perhaps yours differs) of docs\ReleaseProcess.md so I guess we should have an issue for that and discuss in triage.

Example: PR #4739 added a file to the release/1.0 branch but not to main. Why should that file not be in main as well? Do we really think it won't be needed for 1.1? Moving main to 1.1 before that file is present would mean that the baseline for 1.x does not include it.

My apologies for not responding to this thread sooner. I have updated the release process markdown to reflect that the main should be ahead of the latest release branch by 1 minor version.
Since the latest release branch is 1.0, the main should be 1.1.
I agree that ideally the main should have been updated to 1.0 before we forked the release/1.0 branch. Regrettably that did not happen.
We will be mindful that the main does not skip any versions in the future.
Hope the markdown clarifies the issue to your satisfaction.