Fully supported, with no objections on my part. > Off the mailing list: > > Just wanted to highlight this to you, as I saw you had both JIRA and > GitHub issues about problems in the release process that I can fully > confirm after spending time on this. The documentation is inconsistent > on this (or one could even say the current process is just broken!), > especially if you compare e.g. platforms vs. plugins. > > By unifying on one kind of process, I could clean that up and probably > create a pretty much fully automated release process.
@janpio I would like to thank you for the time you have been taking to make the badly needed documentation updates over the past few weeks. I am very sorry that I have not been able to pay closer attention, due to some other commitments and priorities. On Sun, May 26, 2019 at 6:18 PM Jan Piotrowski <piotrow...@gmail.com> wrote: > > Hi all, > > in the last few days I spent quite a lot of time trying to write an > abstracted release process documentation for all our different > components (as a base for some automation). During that, I discovered > that we actually have 2 very different release processes. > > It boils down to these two variants: > > > a) after release, `master` gets a minor bump > > > Prepares `master` for future development already: It gives version > > (`package.json`, `VERSION` and similar) a minor bump and adds `-dev` (=> > > `5.1.0-dev`) back > > ... > > coho prepare-platform-release-branch --version 5.0.0 -r android > > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#create-release-branch > https://github.com/apache/cordova-coho/blob/c37742fafe3c7d0342a2b8deeb6aff41e100f7ad/src/platform-release.js#L34-L44 > > This results in `master` that can not be merged into release branch > any more even if there were no actual new features added that would > require the patch bump (as the release branch can only accept patch > increases, and merging would merge a minor increase). > > > b) after release, `master` gets a patch bump > > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#interactive-plugins-release > https://github.com/apache/cordova-coho/blob/c37742fafe3c7d0342a2b8deeb6aff41e100f7ad/src/plugin-release.js#L561 > First command includes a patch bump: > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#update-version-to-add-back--dev-suffix > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md#re-introduce--dev-suffix-to-versions-on-master-and-commit > https://github.com/apache/cordova-coho/blob/master/docs/app-hello-world-release-process.md#re-introduce--dev-suffix-to-versions-on-master > https://github.com/apache/cordova-coho/blob/master/docs/coho-release-process.md#re-introduce--dev-suffix-to-versions-on-master-and-commit > > This results in a `master` that can just be merged into the release branch. > > > There are also differences when a release branch is created, how and > if the release branch is updated, when `-dev` is removed and re-added, > on which branch the actual tag is created, how a negative vote result > is handled on the repo, if the release branch also gets an automated > bump after release - but those are all outcomes of that very first > difference. > > > I suggest we unify our release processes on variant b), as it is > simpler and more flexible. If new features are added, the minor bump > to the version string should be a conscious change, not something that > is assumed at the time of previous release already. > > Any objections? > Who supports this? > > Best, > Jan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
