cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Releases in a 3.0 World
Date Thu, 05 Sep 2013 02:32:58 GMT
On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Changes should sneak into dev, not master. Unless someone else messed
> something up, there shouldn't be any conflicts on master.
>
> I see what you're saying though. Sneaking a change into dev while you're
> testing would mess you up a bit.
>
> One option is to push after incrementing the version and writing the
> changelog, that way subsequent changes will happen after your merge point
> just fine. It means that you'll have a non-dev version on master for a bit,
> but I think that's fine. Small window.


Would this be any easier if coho had the ability to maintain, say in a
small text file, a list of repos and their associated hashes, as a kind of
'snapshot'? Coho could output that format based on what it sees at a given
time, and then could use it again as input when performing certain git
operations.

Something like this:

$ coho snapshot
{"cordova-android": "8091a2b3c4d5e6f708192a3b4c5d6e7f",
"cordova-ios": "abcd1234...",
"cordova-plugin-camera": ...,
...
}

Then, you could use that to snapshot the plugin state before starting the
release tests, and use it when merging:

$ coho snapshot -r plugins > CURRENT_VERSIONS
... testing follows ...
... ready to commit ...
$ coho foreach -r plugins "git checkout master"
$ coho foreach -r plugins --use-snapshot CURRENT_VERSIONS "git merge
__REVISION__ --ff-only"

Coho would use the appropriate hash in place of __REVISION__ (or some other
placeholder) for each repo in the foreach loop.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message