[
https://issues.apache.org/jira/browse/CB-14249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Brody updated CB-14249:
-----------------------------
Description:
The procedure for tools release is that once the tools release is made, version
must be incremented to new -dev version. This does not seem to be the case for
platforms release.
I think we did not catch this for a long time since the coho tools
automatically marks new "-dev" version in master, in case of release from
master. But in case of release from non-master branch this does not seem to be
the case.
This should be relatively straightforward except for another factor: in case a
proposed release does not pass the vote the procedure is different: for tools
it says we should go on with the next release while for platforms it says we
should do a revert to go back to the previous "-dev" before fixing. I think
this inconsistency should also be resolved, somehow.
As a workaround I would mark the "-dev" version in a patch branch before
committing any changes to a non-master branch, for example:
https://github.com/apache/cordova-android/pull/470
P.S. I think it would be best to get agreement via
[mailto:[email protected]], cannot tell for sure when I will get a chance
to do this.
was:
The procedure for tools release is that once the tools release is made, version
must be incremented to new -dev version. This does not seem to be the case for
platforms release.
I think we did not catch this for a long time since the coho tools
automatically marks new "-dev" version in master, in case of release from
master. But in case of release from non-master branch this does not seem to be
the case.
This should be relatively straightforward except for another factor: in case a
proposed release does not pass the vote the procedure is different: for tools
it says we should go on with the next release while for platforms it says we
should do a revert to go back to the previous "-dev" before fixing. I think
this inconsistency should also be resolved, somehow.
As a workaround I would mark the "-dev" version in a patch branch before
committing any changes to a non-master branch, for example:
https://github.com/apache/cordova-android/pull/470
> Inconsistency in platforms vs tools release in cordova-coho docs
> ----------------------------------------------------------------
>
> Key: CB-14249
> URL: https://issues.apache.org/jira/browse/CB-14249
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-coho
> Reporter: Chris Brody
> Assignee: Chris Brody
> Priority: Major
>
> The procedure for tools release is that once the tools release is made,
> version must be incremented to new -dev version. This does not seem to be the
> case for platforms release.
> I think we did not catch this for a long time since the coho tools
> automatically marks new "-dev" version in master, in case of release from
> master. But in case of release from non-master branch this does not seem to
> be the case.
> This should be relatively straightforward except for another factor: in case
> a proposed release does not pass the vote the procedure is different: for
> tools it says we should go on with the next release while for platforms it
> says we should do a revert to go back to the previous "-dev" before fixing. I
> think this inconsistency should also be resolved, somehow.
> As a workaround I would mark the "-dev" version in a patch branch before
> committing any changes to a non-master branch, for example:
> https://github.com/apache/cordova-android/pull/470
> P.S. I think it would be best to get agreement via
> [mailto:[email protected]], cannot tell for sure when I will get a
> chance to do this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
