[GitHub] erisu opened a new issue #227: Commits not applied to master

[GitBox <gi...@apache.org>]

erisu opened a new issue #227: Commits not applied to master
URL: https://github.com/apache/cordova-coho/issues/227
 
 
   ## Background
   Per @brodybits comment on the VOTE thread
   
   > 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. 
   
   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.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org