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 13:14:22 GMT
On Thu, Sep 5, 2013 at 5:45 AM, Plaquette, Paul <paul.plaquette@intel.com>wrote:

> hi,
>
>
> good idea.
>
> could not it create tags ? (in order to have something more readable than a
> hash)
>

I suppose it could, as long as you didn't push them until they're tested --
my reason for not suggesting that is that you may need to re-test as
problems are fixed, and once you push tags to a public repo, they should be
permanent.

I just wanted a quick way to save state locally, without changing anything
unnecessarily in the git repo itself. Just a way to say "save all of the
current hashes. Now do this to all of the repos, given these hashes that we
saved before". It shouldn't need to tag them all in order to do that.

As far as readability goes, I don't think it needs to be readable by
anything except coho itself. That said, git hashes are a pretty commonly
encountered type of string. Anyone who has worked with git should
understand what they are and how to use them, even if they are just opaque
identifiers rather than meaningful words.

Ian


> Cordially
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Paul Plaquette,
> Senior Software Engineer
> Intel Corporation SAS *
> *
> *SSG/OTC: Open Source Technology Center*
> France, Montpellier
>
>
>
> On Thu, Sep 5, 2013 at 4:32 AM, Ian Clelland <iclelland@chromium.org>
> wrote:
>
> > 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.
> > ---------------------------------------------------------------------
> > Intel Corporation SAS (French simplified joint stock company)
> > Registered headquarters: "Les Montalets"- 2, rue de Paris,
> > 92196 Meudon Cedex, France
> > Registration Number:  302 456 199 R.C.S. NANTERRE
> > Capital: 4,572,000 Euros
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
>

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