cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 23:33:09 GMT
get a babycarrier :) although you would then have to type with your arms
extended and further away from your screen (external keyboard I suppose)


On Mon, Jul 15, 2013 at 4:26 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> huzzah! great.
>
> btw - im still learning to type with a baby in one arm :)
>
> that command doesnt exist in coho.
>
> ./cordova-coho/coho repo-update -b 3.0.x -r REPOS
>
> comes close, but wont change branch if there were no changes.
>
>
> On Mon, Jul 15, 2013 at 7:15 PM, Steven Gill <stevengill97@gmail.com>
> wrote:
>
> > Hey Andrew,
> >
> > I posted in here before reading the getting organized for 3.0 thread. I
> > retract my statement that every plugin needs issues and agree with
> plugins
> > being tested by platform maintainers before they tag their respective
> > platforms. I created one issue to tag all of the plugins once platforms
> are
> > tagged.
> >
> >
> > On Mon, Jul 15, 2013 at 4:12 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > So, since we're stuck with coho if we want to get this done this week,
> > > how do you get coho to check out a branch of all the plugins?
> > >
> > > On Mon, Jul 15, 2013 at 4:10 PM, Andrew Grieve <agrieve@chromium.org>
> > > wrote:
> > > > On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill <stevengill97@gmail.com
> >
> > > wrote:
> > > >
> > > >> We will need to add issues for tagging plugins.
> > > >
> > > > What's your reasoning?
> > > >
> > > >
> > > >
> > > >> I can create the issue and
> > > >> tag the plugins. I figure for now, plugins will use same tagging
> > > process as
> > > >> other repos.
> > > >>
> > > > And that process is?
> > > >
> > > > For the RC - it's trivial to create release branches and an RC tag.
> > coho
> > > > can do it in bulk. The main question is what criteria should we use
> to
> > > > determine whether a plugin is ready for tagging? For an RC, we could
> > just
> > > > tag with whatever's there , but then it's not really adding any
> meaning
> > > on
> > > > top of the release branch existing. I think the thing that separates
> > the
> > > > release branch from the tag is some testing.
> > > >
> > > >
> > > >>
> > > >>
> > > >> On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj <fil@adobe.com>
wrote:
> > > >>
> > > >> > Created the issues: https://issues.apache.org/jira/browse/CB-4208
> > > >> >
> > > >> > On 7/15/13 11:56 AM, "Joe Bowser" <bowserj@gmail.com> wrote:
> > > >> >
> > > >> > >So, for tagging today, can we get the issues setup and the
JS
> > tagged
> > > >> > >at least? We can somehow muddle through this RC1.
> > > >> > >
> > > >> > >On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux <b@brian.io>
> wrote:
> > > >> > >> I'd say we could consider the core plugins as build
ephemera
> not
> > > >> > >> unlike docs or automations. Really cordova-cli is the
main
> point
> > of
> > > >> > >> interaction between us and our developer community.
> > > >> > >>
> > > >> > >>
> > > >> > >> On Mon, Jul 15, 2013 at 9:03 AM, Andrew Grieve <
> > > agrieve@chromium.org>
> > > >> > >>wrote:
> > > >> > >>> The Apache Way was a part of what I was thinking
as well.
> > > >> > >>>
> > > >> > >>> Also - it occurs to me that we'll have to change
our voting
> > system
> > > >> > >>>when it
> > > >> > >>> comes to plugins since each plugin repo should have
a +1 from
> > each
> > > >> > >>>platform
> > > >> > >>> maintainer, and can be tagged only once.
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> On Fri, Jul 12, 2013 at 12:53 PM, Joe Bowser <
> bowserj@gmail.com
> > >
> > > >> > wrote:
> > > >> > >>>
> > > >> > >>>> Don't we have to release a zip on an Apache
server because of
> > > "The
> > > >> > >>>> Apache Way"?  That's why I thought we had to
release
> artifacts,
> > > not
> > > >> > >>>> for people, but for process.
> > > >> > >>>>
> > > >> > >>>> On Fri, Jul 12, 2013 at 9:31 AM, Brian LeRoux
<b@brian.io>
> > > wrote:
> > > >> > >>>> > I don't mind this but it seems like a lot
of work to
> release
> > > >> > >>>>artifacts
> > > >> > >>>> > for...who? End users we want to encourage
to use the
> tooling
> > > >> golden
> > > >> > >>>> > path for creating projects, working w/
plugins, etc.
> > > >> > >>>> >
> > > >> > >>>> > If anything I'd rather we *only* distribute
cordova-cli as
> > the
> > > >> > >>>> > canonical repo and entry point for usage
and treat the rest
> > as
> > > our
> > > >> > >>>> > project build artifacts/ephemera.
> > > >> > >>>> >
> > > >> > >>>> > Way easier. Way more in tune w/ actual
usage.
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> > On Fri, Jul 12, 2013 at 7:25 AM, Andrew
Grieve
> > > >> > >>>><agrieve@chromium.org>
> > > >> > >>>> wrote:
> > > >> > >>>> >> Definitely would like to get everything
Release /
> Versioning
> > > >> > >>>>related
> > > >> > >>>> >> documented on the wiki. The most complete
source right now
> > is:
> > > >> > >>>> >> http://wiki.apache.org/cordova/CuttingReleases
We should
> > add
> > > >> > >>>>another
> > > >> > >>>> page
> > > >> > >>>> >> for versioning once we settle on what
to do with plugins.
> > > >> > >>>> >>
> > > >> > >>>> >> Right now only CLI & Plugman are
distributed on npm and
> are
> > > >> > >>>>versioned
> > > >> > >>>> >> separately. Nothing else is on npm
though, so package.json
> > > isn't
> > > >> > >>>>used.
> > > >> > >>>> >> Instead VERSION files hold the version.
> > > >> > >>>> >>
> > > >> > >>>> >> I've decided I didn't like my previous
proposal of not
> > > updating
> > > >> > >>>>versions
> > > >> > >>>> >> when things don't change because it
will make it harder to
> > > check
> > > >> > >>>>out a
> > > >> > >>>> >> version of Cordova.
> > > >> > >>>> >>
> > > >> > >>>> >> New Proposal:
> > > >> > >>>> >>
> > > >> > >>>> >> 1. Each Cordova release will include:
> > > >> > >>>> >>  - A copy of every repo, including
all core plugins.
> > > >> > >>>> >>
> > > >> > >>>> >> 2. Each plugin repo will get a release
branch even if the
> > code
> > > >> > >>>>hasn't
> > > >> > >>>> >> changed.
> > > >> > >>>> >>
> > > >> > >>>> >> 3. Each plugin's version will match
the Cordova version
> > > >> > >>>> >>
> > > >> > >>>> >> 4. Plugins can have separate point
releases if they are
> > > important
> > > >> > >>>> updates
> > > >> > >>>> >> to them. These will be in the form
of tags along the
> release
> > > >> > >>>>branch.
> > > >> > >>>> >>
> > > >> > >>>> >> 5. As soon as release branches are
created, we change the
> > > VERSION
> > > >> > >>>>file
> > > >> > >>>> and
> > > >> > >>>> >> re-tag master to a -dev version of
the next release (e.g.
> > > >> > >>>>3.1.0-dev)
> > > >> > >>>> >>
> > > >> > >>>> >>
> > > >> > >>>> >> On Thu, Jul 11, 2013 at 9:05 AM, Carlos
Santana
> > > >> > >>>><csantana23@gmail.com
> > > >> > >>>> >wrote:
> > > >> > >>>> >>
> > > >> > >>>> >>> Dumb questions
> > > >> > >>>> >>>
> > > >> > >>>> >>> Does the package.json {version:""}
field needs to be
> > updated
> > > on
> > > >> > >>>>every
> > > >> > >>>> >>> commit to the repo?
> > > >> > >>>> >>>   (meaning depending what is the
commit, then the major,
> > > minor,
> > > >> > >>>>patch,
> > > >> > >>>> or
> > > >> > >>>> >>> extension gets updated)
> > > >> > >>>> >>> Does the npm registry support pre-release
and build
> > metadata
> > > >> (i.e.
> > > >> > >>>> x.7.z.92
> > > >> > >>>> >>> in 2.9.1-x.7.z.92)?
> > > >> > >>>> >>> If this true, Does npm knows to
install the latest stable
> > > >> > >>>>version, but
> > > >> > >>>> user
> > > >> > >>>> >>> can request a pre-release by specifying
the version that
> it
> > > >> wants
> > > >> > >>>>@2
> > > >> > >>>> >>> .9.1-x.7.z.92
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>> Refs:
> > > >> > >>>> >>> http://semver.org/
> > > >> > >>>> >>>
> > > >> > >>>> >>> Given a version number MAJOR.MINOR.PATCH,
increment the:
> > > >> > >>>> >>>
> > > >> > >>>> >>>    1. MAJOR version when you make
incompatible API
> changes,
> > > >> > >>>> >>>    2. MINOR version when you add
functionality in a
> > > >> > >>>> backwards-compatible
> > > >> > >>>> >>>    manner, and
> > > >> > >>>> >>>    3. PATCH version when you make
backwards-compatible
> bug
> > > >> fixes.
> > > >> > >>>> >>>
> > > >> > >>>> >>> *Additional labels for pre-release
and build metadata are
> > > >> > >>>>available as
> > > >> > >>>> >>> extensions to the MAJOR.MINOR.PATCH
format.*
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>> On Thu, Jul 11, 2013 at 8:57 AM,
Carlos Santana
> > > >> > >>>><csantana23@gmail.com
> > > >> > >>>> >>> >wrote:
> > > >> > >>>> >>>
> > > >> > >>>> >>> > About versioning maybe we
should open a
> > > >> > >>>>mail-thread/jira/wikipage
> > > >> > >>>> (not
> > > >> > >>>> >>> > familiar with process yet
:-))
> > > >> > >>>> >>> > To discuss and be clear what
is the guideline/process
> to
> > > >> version
> > > >> > >>>> >>> different
> > > >> > >>>> >>> > components.
> > > >> > >>>> >>> >
> > > >> > >>>> >>> > Some thoughts (maybe this
is already well understood
> and
> > > >> > >>>>documented
> > > >> > >>>> in
> > > >> > >>>> >>> > wiki):
> > > >> > >>>> >>> > - Lets follow semantic versioning
as much as possible
> for
> > > ALL
> > > >> > >>>> components
> > > >> > >>>> >>> > (i.e. plugins, core, cli,
plugman, platform, repos)
> > > >> > >>>> >>> > - Document the deliverables/releases
channels (i.e.
> npm,
> > > >> apache
> > > >> > >>>> zip/dist,
> > > >> > >>>> >>> > git repo)
> > > >> > >>>> >>> > - Maintain the versions in
sync (package.json
> > {version:""},
> > > >> git
> > > >> > >>>>tag)
> > > >> > >>>> >>> > tag/hash should match what's
posted in npm registry?
> > > >> > >>>> >>> >
> > > >> > >>>> >>> > --Carlos
> > > >> > >>>> >>> >
> > > >> > >>>> >>> >
> > > >> > >>>> >>> > On Wed, Jul 10, 2013 at 7:33
PM, Andrew Grieve
> > > >> > >>>><agrieve@chromium.org
> > > >> > >>>> >>> >wrote:
> > > >> > >>>> >>> >
> > > >> > >>>> >>> >> Coho started as just a
tool to package, but has grown
> > > into a
> > > >> > >>>>tool
> > > >> > >>>> that:
> > > >> > >>>> >>> >> a) helps work with multiple
repos
> > > >> > >>>> >>> >> b) documents our release
process in working code.
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >> re windows tagging - As
of the last release bug
> > template,
> > > >> we're
> > > >> > >>>> tagging
> > > >> > >>>> >>> >> each branch individually
either via coho or not, so no
> > > issue
> > > >> > >>>>there.
> > > >> > >>>> It
> > > >> > >>>> >>> >> won't be tagged by coho
unless someone does it
> > > explicitly. I
> > > >> > >>>>think
> > > >> > >>>> we
> > > >> > >>>> >>> can
> > > >> > >>>> >>> >> still use it to create
the windows release branches,
> > > since if
> > > >> > >>>>it
> > > >> > >>>> messes
> > > >> > >>>> >>> up
> > > >> > >>>> >>> >> we can just fix what it
missed (but all it does is
> > update
> > > >> > >>>>VERSION
> > > >> > >>>> and
> > > >> > >>>> >>> >> cordova.js).
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >> As for plugins, I've only
used CLI by pointing at
> > > directories
> > > >> > >>>>so
> > > >> > >>>> far,
> > > >> > >>>> >>> but
> > > >> > >>>> >>> >> I
> > > >> > >>>> >>> >> was under the impression
that if you give it a URL,
> you
> > > have
> > > >> to
> > > >> > >>>> give it
> > > >> > >>>> >>> a
> > > >> > >>>> >>> >> repo + subdirectory +
hash/tag combination. If it's
> > > currently
> > > >> > >>>>just
> > > >> > >>>> >>> >> installing from master,
I think that's a bad default
> and
> > > >> should
> > > >> > >>>> instead
> > > >> > >>>> >>> go
> > > >> > >>>> >>> >> by a tag (npm goes by
the "stable" tag by default I
> > > believe).
> > > >> > >>>>So...
> > > >> > >>>> we
> > > >> > >>>> >>> >> will
> > > >> > >>>> >>> >> need an explicit action
for commits to a plugin to be
> > > picked
> > > >> > >>>>up by
> > > >> > >>>> >>> >> plugman.
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >> How about if a plugin
has a commit that is urgent, it
> > > gets a
> > > >> > >>>>point
> > > >> > >>>> >>> release
> > > >> > >>>> >>> >> right away. Otherwise,
it waits for the next Cordova
> > > release
> > > >> > >>>>cycle.
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >> On Wed, Jul 10, 2013 at
6:47 PM, Jesse
> > > >> > >>>><purplecabbage@gmail.com>
> > > >> > >>>> wrote:
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >> > re: COHO
> > > >> > >>>> >>> >> > I cannot guarantee
the output of windows/phone
> > releases
> > > if
> > > >> > >>>>they
> > > >> > >>>> are
> > > >> > >>>> >>> >> tagged
> > > >> > >>>> >>> >> > and updated via coho.
I like the idea of having
> > > continuous
> > > >> > >>>> >>> integration,
> > > >> > >>>> >>> >> but
> > > >> > >>>> >>> >> > this is not there
yet.  I would prefer for now to
> > > manually
> > > >> > >>>>update
> > > >> > >>>> and
> > > >> > >>>> >>> >> tag
> > > >> > >>>> >>> >> > wp7+wp8+windows8
repos because I do not currently
> > trust
> > > the
> > > >> > >>>>magic
> > > >> > >>>> in
> > > >> > >>>> >>> >> coho,
> > > >> > >>>> >>> >> > and do not have time
to go and understand all of the
> > > magic.
> > > >> > >>>> >>> >> >
> > > >> > >>>> >>> >> > @purplecabbage
> > > >> > >>>> >>> >> > risingj.com
> > > >> > >>>> >>> >> >
> > > >> > >>>> >>> >> >
> > > >> > >>>> >>> >> > On Wed, Jul 10, 2013
at 3:36 PM, Steven Gill <
> > > >> > >>>> stevengill97@gmail.com>
> > > >> > >>>> >>> >> > wrote:
> > > >> > >>>> >>> >> >
> > > >> > >>>> >>> >> > > Plugin versioning
is definitely something we need
> to
> > > >> > >>>>discuss in
> > > >> > >>>> >>> >> detail.
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > > What happens
if I make a change to the camera
> > plugin.
> > > Do
> > > >> I
> > > >> > >>>> >>> immediately
> > > >> > >>>> >>> >> > bump
> > > >> > >>>> >>> >> > > the version?
Probably not. But people who install
> it
> > > >> using
> > > >> > >>>> >>> plugman/cli
> > > >> > >>>> >>> >> > > after the change
will get the latest one on master
> > > with
> > > >> no
> > > >> > >>>> obvious
> > > >> > >>>> >>> >> > > difference to
them. Version wise it is the same as
> > > before
> > > >> > >>>>the
> > > >> > >>>> >>> change.
> > > >> > >>>> >>> >> > This
> > > >> > >>>> >>> >> > > feels wrong.
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > > We can now update
plugins independently of our
> once
> > a
> > > >> month
> > > >> > >>>> release
> > > >> > >>>> >>> >> and
> > > >> > >>>> >>> >> > get
> > > >> > >>>> >>> >> > > those updates
to our users instantly. I think we
> > > should
> > > >> > >>>>update
> > > >> > >>>> the
> > > >> > >>>> >>> >> > version
> > > >> > >>>> >>> >> > > of the plugins
after every change. Similar to
> > > >> node-modules
> > > >> > >>>>on
> > > >> > >>>>  npm.
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > > Coho is not
just for packaging. I love the fact
> > that I
> > > >> can
> > > >> > >>>> clone and
> > > >> > >>>> >>> >> > update
> > > >> > >>>> >>> >> > > all of the repos
in a few quick commands. Coho
> seems
> > > to
> > > >> > >>>>have the
> > > >> > >>>> >>> >> ability
> > > >> > >>>> >>> >> > to
> > > >> > >>>> >>> >> > > do tagging,
release packaging and signing,
> uploading
> > > >> > >>>>releases to
> > > >> > >>>> >>> >> apache,
> > > >> > >>>> >>> >> > > cloning all
repos and soon generating release
> issues
> > > on
> > > >> > >>>>jira. It
> > > >> > >>>> >>> will
> > > >> > >>>> >>> >> be
> > > >> > >>>> >>> >> > > important to
solve all of the issues people are
> > having
> > > >> with
> > > >> > >>>> coho and
> > > >> > >>>> >>> >> > > document what
you can do with it.
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > > On Wed, Jul
10, 2013 at 3:15 PM, Joe Bowser
> > > >> > >>>><bowserj@gmail.com>
> > > >> > >>>> >>> >> wrote:
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > > > I'm going
to create a new thread about this, but
> > > what's
> > > >> > >>>>the
> > > >> > >>>> >>> purpose
> > > >> > >>>> >>> >> of
> > > >> > >>>> >>> >> > > > coho again?
I thought it was just for packaging
> > > >> releases.
> > > >> > >>>> >>> >> > > >
> > > >> > >>>> >>> >> > > > On Wed,
Jul 10, 2013 at 3:07 PM, Andrew Grieve <
> > > >> > >>>> >>> >> agrieve@chromium.org>
> > > >> > >>>> >>> >> > > > wrote:
> > > >> > >>>> >>> >> > > > > Our
intern Jeffrey is actively working on
> > adding a
> > > >> > >>>>command
> > > >> > >>>> to
> > > >> > >>>> >>> >> coho to
> > > >> > >>>> >>> >> > > be
> > > >> > >>>> >>> >> > > > > able
to create release bugs (based off of
> > > >> > >>>>cordova-labs). If
> > > >> > >>>> he
> > > >> > >>>> >>> >> gets
> > > >> > >>>> >>> >> > > done,
> > > >> > >>>> >>> >> > > > > by
Monday, then it'll be a cinch to create the
> > > >> issues.
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > > We
could maybe start by discussing what we
> want
> > > to do
> > > >> > >>>>with
> > > >> > >>>> the
> > > >> > >>>> >>> >> plugin
> > > >> > >>>> >>> >> > > > repos
> > > >> > >>>> >>> >> > > > > for
the release.
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > > Should
they all have release branches?
> > > >> > >>>> >>> >> > > > > Should
they be versioned the same? e.g. 3.0.x,
> > or
> > > >> > >>>>should
> > > >> > >>>> they
> > > >> > >>>> >>> >> start
> > > >> > >>>> >>> >> > out
> > > >> > >>>> >>> >> > > > at
> > > >> > >>>> >>> >> > > > > 1.0.x?
> > > >> > >>>> >>> >> > > > > Are
we including a .zip of all of them in our
> > > apache
> > > >> > >>>> >>> distribution
> > > >> > >>>> >>> >> > .zip?
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > > Here's
a stab at it from me:
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > > -
Always include all core plugins in the
> apache
> > > >> > >>>>release .zip
> > > >> > >>>> >>> >> > > > > -
If a plugin has not changed since the
> previous
> > > >> > >>>>release,
> > > >> > >>>> then
> > > >> > >>>> >>> >> just
> > > >> > >>>> >>> >> > put
> > > >> > >>>> >>> >> > > > in
> > > >> > >>>> >>> >> > > > > the
previous release of the .zip.
> > > >> > >>>> >>> >> > > > >  
 - E.g. for 3.1.0, if plugin-console has no
> > > >> changes,
> > > >> > >>>>then
> > > >> > >>>> just
> > > >> > >>>> >>> >> > > package
> > > >> > >>>> >>> >> > > > > version
3.0.0 of the plugin in the release
> > > >> > >>>> >>> >> > > > > -
Create release branches for the plugin repos
> > > only
> > > >> if
> > > >> > >>>> there has
> > > >> > >>>> >>> >> > been a
> > > >> > >>>> >>> >> > > > > commit
since the previous release
> > > >> > >>>> >>> >> > > > >  
 - If there were no commits, then there
> cannot
> > > be
> > > >> any
> > > >> > >>>> >>> >> regressions,
> > > >> > >>>> >>> >> > so
> > > >> > >>>> >>> >> > > > no
> > > >> > >>>> >>> >> > > > > need
for a release branch.
> > > >> > >>>> >>> >> > > > > -
I think they should be versioned the same to
> > > help
> > > >> us
> > > >> > >>>> figure
> > > >> > >>>> >>> out
> > > >> > >>>> >>> >> > when
> > > >> > >>>> >>> >> > > > the
> > > >> > >>>> >>> >> > > > > last
change was.
> > > >> > >>>> >>> >> > > > >  
 - This could mean that if plugin-console
> goes
> > > >> three
> > > >> > >>>> months
> > > >> > >>>> >>> >> > without a
> > > >> > >>>> >>> >> > > > > change,
it will go from 3.0.0 straight to
> 3.3.0
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > > On
Wed, Jul 10, 2013 at 5:50 PM, Filip Maj
> > > >> > >>>><fil@adobe.com>
> > > >> > >>>> >>> wrote:
> > > >> > >>>> >>> >> > > > >
> > > >> > >>>> >>> >> > > > >>
Yeah.. Maybe we should create the issues for
> > the
> > > rc
> > > >> > >>>>soon?
> > > >> > >>>> >>> >> > > > >>
> > > >> > >>>> >>> >> > > > >>
On 7/10/13 1:57 PM, "Andrew Grieve"
> > > >> > >>>><agrieve@chromium.org>
> > > >> > >>>> >>> >> wrote:
> > > >> > >>>> >>> >> > > > >>
> > > >> > >>>> >>> >> > > > >>
>I would put that at next week unless someone
> > has
> > > >> > >>>>cycles
> > > >> > >>>> to get
> > > >> > >>>> >>> >> on
> > > >> > >>>> >>> >> > it
> > > >> > >>>> >>> >> > > > this
> > > >> > >>>> >>> >> > > > >>
>week.
> > > >> > >>>> >>> >> > > > >>
>
> > > >> > >>>> >>> >> > > > >>
>
> > > >> > >>>> >>> >> > > > >>
>On Wed, Jul 10, 2013 at 4:24 PM, Marcel
> > Kinard <
> > > >> > >>>> >>> >> cmarcelk@gmail.com
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> > > > >>
wrote:
> > > >> > >>>> >>> >> > > > >>
>
> > > >> > >>>> >>> >> > > > >>
>> When will the Upgrade Guides (2.9 -> 3.0)
> be
> > > >> > >>>>written?
> > > >> > >>>> That
> > > >> > >>>> >>> >> > content
> > > >> > >>>> >>> >> > > is
> > > >> > >>>> >>> >> > > > >>
>> currently not in cordova-docs.
> > > >> > >>>> >>> >> > > > >>
> > > >> > >>>> >>> >> > > > >>
> > > >> > >>>> >>> >> > > >
> > > >> > >>>> >>> >> > >
> > > >> > >>>> >>> >> >
> > > >> > >>>> >>> >>
> > > >> > >>>> >>> >
> > > >> > >>>> >>> >
> > > >> > >>>> >>> >
> > > >> > >>>> >>> > --
> > > >> > >>>> >>> > Carlos Santana
> > > >> > >>>> >>> > <csantana23@gmail.com>
> > > >> > >>>> >>> >
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>> --
> > > >> > >>>> >>> Carlos Santana
> > > >> > >>>> >>> <csantana23@gmail.com>
> > > >> > >>>> >>>
> > > >> > >>>>
> > > >> >
> > > >> >
> > > >>
> > >
> >
>

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