[ 
https://issues.apache.org/jira/browse/CB-14249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567391#comment-16567391
 ] 

ASF GitHub Bot commented on CB-14249:
-------------------------------------

brodybits commented on issue #189: [WIP] CB-14249 ensure platform changes are 
in a dev version (partial workaround doc fix)
URL: https://github.com/apache/cordova-coho/pull/189#issuecomment-410040220
 
 
   Thanks @janpio for the feedback. I would definitely agree that the command 
is missing and that we should get rid of "manually". The thing is that I think 
we really need some of the changes I proposed in #188 for the coho command to 
work in the release branch. I just updated the description with this info.
   
   There a few things I want to do first, major one is to finish the Cordova 
patch release before cleaning up #188. Keeping this one as "WIP" for now.

----------------------------------------------------------------
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:
[email protected]


> 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]

Reply via email to