A minor comment is that I noticed the commit for the git tag does not seem to be in the master branch, which I would have expected for a major release.
Releases are not blocked
For now, it should be OK to continue the releases even though the commit ID does not exist on the master branch.
Purpose of Ticket
This GH ticket is to track and discuss the expectation outlines by the comment above and how we can improve the platform releasing process to meet this expectation. OR come to a consensus that the current behavior is as is and that improvements are not to be performed.
If improvements are needed, the current priority is really low and does not block releases. We just need to plan and schedule.
Personally, I can also agree that it is expected for the master branch to have the same commits of the releasing branch. No matter what type of releases (major, minor or patch).
Why this happened?
It seems what is being seen and reported in the comment comes from the coho prepare-platform-release-branch command.
Basically, IMO, what is happening is that coho performs two of the steps twice. Once on the new or existing branch for the targeting release, and lastly once on the master branch for preparing a future release.
A Solution (Opinion)
Ideally, IMO, it would perform these steps on the master branch first for the targeting release, then create a new branch from the master branch. This would make the master branch and new release branch identical. Then on the master branch perform the preparing future release commits. The master branch to have two extra commits would be expected.
The above only covers the major and minor release case these require a new branch to be created. For existing branches, patch releases, it would need a cherry-pick instead. This might be a bit more difficult to automate.
Other
As wild guess, the reason why it may perform the way it does now was that finding commit ids to do a cherry-picking process for a patch release was a bit difficult so direct commits were maybe easier. In that case release code for major, minor or patch would be identical.
brodycj
commented
5 years ago
Background
Per @brodybits comment on the VOTE thread
Releases are not blocked
For now, it should be OK to continue the releases even though the commit ID does not exist on the master branch.
Purpose of Ticket
This GH ticket is to track and discuss the expectation outlines by the comment above and how we can improve the platform releasing process to meet this expectation. OR come to a consensus that the current behavior is as is and that improvements are not to be performed.
If improvements are needed, the current priority is really low and does not block releases. We just need to plan and schedule.
Personally, I can also agree that it is expected for the master branch to have the same commits of the releasing branch. No matter what type of releases (major, minor or patch).
Why this happened?
It seems what is being seen and reported in the comment comes from the
coho prepare-platform-release-branchcommand.See the documentation, for the outlining process of the command: https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#create-release-branch
Basically, IMO, what is happening is that coho performs two of the steps twice. Once on the new or existing branch for the targeting release, and lastly once on the master branch for preparing a future release.
A Solution (Opinion)
Ideally, IMO, it would perform these steps on the master branch first for the targeting release, then create a new branch from the master branch. This would make the master branch and new release branch identical. Then on the master branch perform the preparing future release commits. The master branch to have two extra commits would be expected.
The above only covers the major and minor release case these require a new branch to be created. For existing branches, patch releases, it would need a cherry-pick instead. This might be a bit more difficult to automate.
Other
As wild guess, the reason why it may perform the way it does now was that finding commit ids to do a cherry-picking process for a patch release was a bit difficult so direct commits were maybe easier. In that case release code for major, minor or patch would be identical.