cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Suggestions for a problem
Date Wed, 09 Apr 2014 14:51:05 GMT
The thing I don't want is platforms in *cli*'s package.json

Introducing a new package.json for each app is something we could consider.
I was just assuming we'd dump it into config.xml instead of creating a new
file. *Either way*, we'd be using npm to do the work.


On Tue, Apr 8, 2014 at 2:41 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> +1 for platforms in package.json
>
>
> On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams <tommy@devgeeks.org> wrote:
>
> > +1 for reapproach
> > On 09/04/2014 8:20 am, "Brian LeRoux" <b@brian.io> wrote:
> >
> > > Hold up! The CLI needs to declare dependencies somehow and while we
> could
> > > implement our own thing npm will do it better. (Hence this thinking.)
> > >
> > > But the good news is we can use >=X.X.X in package.json to allow npm to
> > > download the latest.
> > >
> > > Now that said, it would be cool to allow version pinning, moving away
> > from
> > > config.xml and just using package.json in Cordova projects. This was
> > > brought up a while back but we decided this wasn't a big win. Maybe we
> > can
> > > reapproach.
> > >
> > >
> > > On Apr 9, 2014 6:09 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> > >
> > > > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mmocny@chromium.org>
> > > wrote:
> > > >
> > > > > On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <
> agrieve@chromium.org>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan <
> > gorkem.ercan@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I think a tool can just go through all tagged version of
the
> > CLI's
> > > > > > > platforms.js and create the version map. I guess this
> effectively
> > > > makes
> > > > > > CLI
> > > > > > > versions the Cordova version.
> > > > > > >
> > > > > > That's the way I think of it right now as well
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > I was looking at the phonegap announcement[1], which got
me
> > > > thinking, I
> > > > > > > think independent releases may create complications beyond
the
> > > > problems
> > > > > > > like the one I had. For instance take a moment and try
to
> imagine
> > > how
> > > > > one
> > > > > > > would need to write the same announcement for an independent
> > > release.
> > > > > > >
> > > > > > > By the way, I keep hearing that independent platform releases
> has
> > > not
> > > > > > > happened yet but since iOS has a 3.4.1 release while all
other
> > > > > platforms
> > > > > > > are 3.4.0 and CLI is getting ready for a release that picks
up
> > iOS
> > > > > 3.4.1
> > > > > > > what else is missing for it to happen?
> > > > > > >
> > > > > >
> > > > > > I think if we get this right, we'd be able to release iOS 3.4.1
> > > > *without*
> > > > > > having to release a new version of CLI. Just like you don't
need
> to
> > > > > update
> > > > > > your version of npm when a new version of cordova-cli comes
out.
> > > > > >
> > > > >
> > > > > Does this conflict with the previous statement that tooling
> versions
> > > > match
> > > > > CLI deps?
> > > > >
> > > >
> > > > It does. My hope is that eventually the CLI version won't have any
> > > mapping
> > > > to platform versions. It will just ask npm what the latest version
> is,
> > > and
> > > > use that. If users want to pin their versions, they can do so by
> > > specifying
> > > > the version on the command-line or in their config.xml.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > [1]
> https://twitter.com/PhoneGapBuild/status/453271589803405313
> > > > > > >
> > > > > > > --
> > > > > > > Gorkem
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny <
> > mmocny@chromium.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <shazron@gmail.com>
> > > wrote:
> > > > > > > >
> > > > > > > > > Looks like you will have to generate this yourself
for now.
> > But
> > > > > > correct
> > > > > > > > me
> > > > > > > > > if I'm wrong, if the CLI is at version X.Y.Z,
wouldn't the
> > > > platform
> > > > > > > > > versions be at least X.Y.Z themselves? At least
for the
> main
> > > > > > platforms
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think thats what the proposal was, but as
Joe says,
> > this
> > > > > hasn't
> > > > > > > > happened yet and so is still up in the air.
> > > > > > > >
> > > > > > > > Strictly speaking, if we chose to version everything
with
> > semver,
> > > > the
> > > > > > > > version numbers would diverge over time.  The specific
x.y.z
> of
> > > one
> > > > > > > > artifact would be meaningless when compared to other
> artifacts,
> > > but
> > > > > in
> > > > > > > > exchange potentially more useful when compared to
other
> > versions
> > > of
> > > > > the
> > > > > > > > same artifact.
> > > > > > > >
> > > > > > > > Implicitly, each release happens on a date, and CLI
releases
> > on a
> > > > > given
> > > > > > > > date depend on the latest releases of each platform.
 So, if
> > you
> > > > have
> > > > > > any
> > > > > > > > single artifact, you can get the release date, then
the
> > > > corresponding
> > > > > > CLI
> > > > > > > > release, and finally use that to map backwards to
specific
> > semver
> > > > > > > versions
> > > > > > > > of all platforms.
> > > > > > > >
> > > > > > > > Personally, though, I'm not sure that we are using
Semver to
> > good
> > > > > > effect
> > > > > > > at
> > > > > > > > all, and its just hurting us.  I'd suggest we consider
> > switching
> > > to
> > > > > > > > versioning by date (aka the Ubuntu / Chromium / etc
model).
> > > > > > > >
> > > > > > > >
> > > > > > > > > (android, ios, bb) this would be true I suppose,
at least
> > until
> > > > > 3.5.0
> > > > > > > > (not
> > > > > > > > > sure when we are diverging).
> > > > > > > > >
> > > > > > > > > Since the CLI is tied to certain platform versions,
I don't
> > see
> > > > why
> > > > > > the
> > > > > > > > map
> > > > > > > > > can't be auto generated.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Apr 7, 2014 at 4:44 PM, Gorkem Ercan
<
> > > > > gorkem.ercan@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Would package.json carry the historical
data? At the
> > moment,
> > > my
> > > > > > plan
> > > > > > > is
> > > > > > > > > to
> > > > > > > > > > have a json file that maps CLI versions
to platform
> version
> > > but
> > > > > for
> > > > > > > > every
> > > > > > > > > > version > 3.0.0. It would be great if
such a file is
> > updated
> > > as
> > > > > > part
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > release of CLI though.
> > > > > > > > > > --
> > > > > > > > > > Gorkem
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Apr 7, 2014 at 5:07 PM, Brian LeRoux
<b@brian.io
> >
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Moving to independent platform releases
doesn't change
> > > things
> > > > > > other
> > > > > > > > > than
> > > > > > > > > > a
> > > > > > > > > > > mostly arbitrary number we use for
issue tracking. This
> > is
> > > > the
> > > > > > way
> > > > > > > it
> > > > > > > > > > works
> > > > > > > > > > > today:
> > > > > > > > > > >
> > > > > > > > > > > CLI@X.X.X
> > > > > > > > > > > '- cordova@X.X.X
> > > > > > > > > > >     |-ios@X.X.X
> > > > > > > > > > >     '-android@X.X.X
> > > > > > > > > > >
> > > > > > > > > > > This is how it would work in the new
world order:
> > > > > > > > > > >
> > > > > > > > > > > CLI@X.X.X
> > > > > > > > > > > |- ios@X.X.X
> > > > > > > > > > > '-android@X.X.X
> > > > > > > > > > >
> > > > > > > > > > > This means other tool that depends
on the version
> locked
> > > > > > > convenience
> > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > Cordova release basically will want
to track whatever
> we
> > do
> > > > > with
> > > > > > > the
> > > > > > > > > CLI
> > > > > > > > > > > instead. Convienantly we will having
this in the
> Cordova
> > > > > > > package.json
> > > > > > > > > so,
> > > > > > > > > > > hypothetically, this is super easy.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 8, 2014 at 10:24 AM, Marcel
Kinard <
> > > > > > cmarcelk@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > The way I would summarize this
is that enterprises
> > need a
> > > > way
> > > > > > to
> > > > > > > > > > recreate
> > > > > > > > > > > > a specific environment. This includes
our platforms,
> > > > plugins,
> > > > > > > > > tooling,
> > > > > > > > > > > and
> > > > > > > > > > > > dependencies. Many enterprises
do not desire to live
> on
> > > > head,
> > > > > > > > instead
> > > > > > > > > > > they
> > > > > > > > > > > > want to live at a known reproductable
state. Before
> > 3.0,
> > > > this
> > > > > > was
> > > > > > > > > > pretty
> > > > > > > > > > > > straightforward. After 3.0, and
additionally
> > potentially
> > > > > > > releasing
> > > > > > > > > > > > platforms separately, our definition
of "a Cordova
> > > version"
> > > > > has
> > > > > > > > > > basically
> > > > > > > > > > > > fallen apart (separate timing
for plugins and tools,
> > > > > > > > > non-shrinkwrapped
> > > > > > > > > > > npm
> > > > > > > > > > > > dependencies, etc)
> > > > > > > > > > > >
> > > > > > > > > > > > Perhaps one way to solve this
would be a "Cordova
> > > version"
> > > > > > > > identifier
> > > > > > > > > > > that
> > > > > > > > > > > > is a map to the individual versions
of all the
> > > components,
> > > > > > > similar
> > > > > > > > to
> > > > > > > > > > how
> > > > > > > > > > > > cordova-cli/platforms.js has a
version property for
> > each
> > > > > > > platform,
> > > > > > > > > but
> > > > > > > > > > > > include tools and even plugins.
How often would it
> make
> > > > sense
> > > > > > to
> > > > > > > > > update
> > > > > > > > > > > > that version-map and bump the
Cordova version? There
> > are
> > > > > > probably
> > > > > > > > > > > arguments
> > > > > > > > > > > > for both a cadence schedule as
well as
> > > > > > > > anytime-any-component-changes.
> > > > > > > > > > > >
> > > > > > > > > > > > On Apr 7, 2014, at 5:00 PM, Gorkem
Ercan <
> > > > > > gorkem.ercan@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > With the independent platforms
releases I have
> > started
> > > to
> > > > > run
> > > > > > > > into
> > > > > > > > > a
> > > > > > > > > > > > > problem with my Eclipse tools
that I am looking for
> > > some
> > > > > > > > > suggestions.
> > > > > > > > > > > > >
> > > > > > > > > > > > > In the past, Cordova X.Y.Z
meant all platforms
> would
> > be
> > > > > > tagged
> > > > > > > > and
> > > > > > > > > > > > released
> > > > > > > > > > > > > with X.Y.Z. so if Eclipse
tools needed to download
> > > > Cordova
> > > > > > > > version
> > > > > > > > > > > X.Y.Z,
> > > > > > > > > > > > > it could just do so by using
the X.Y.Z git tag. Now
> > > that
> > > > > > > > platforms
> > > > > > > > > > can
> > > > > > > > > > > do
> > > > > > > > > > > > > independent releases the
X.Y.Z tag for may not
> exist
> > > for
> > > > a
> > > > > > > > release
> > > > > > > > > > for
> > > > > > > > > > > a
> > > > > > > > > > > > > platform. So I actually need
a way to determine
> what
> > > > > platform
> > > > > > > > > > versions
> > > > > > > > > > > go
> > > > > > > > > > > > > together. CLI actually captures
that information on
> > > > > > > platforms.js
> > > > > > > > > for
> > > > > > > > > > > the
> > > > > > > > > > > > > release but this is not enough
for Eclipse tools as
> > it
> > > > does
> > > > > > not
> > > > > > > > > > capture
> > > > > > > > > > > > the
> > > > > > > > > > > > > data for older releases and
Eclipse tools can be
> > > download
> > > > > and
> > > > > > > use
> > > > > > > > > > older
> > > > > > > > > > > > > versions.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is there a place where I
can extract this sort of
> > > > platform
> > > > > > > > version
> > > > > > > > > > > > > information?
> > > > > > > > > > > > > Also in the past, plugins
could define engine
> > > > compatibility
> > > > > > as
> > > > > > > > > below
> > > > > > > > > > > > > <engine name="cordova"
version="1.7.0" />
> > > > > > > > > > > > > How does plugman act with
the independent releases
> > now?
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Gorkem
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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