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:53:15 GMT
One nice thing about putting them in config.xml, is that we can separate
them from plugins.
e.g.

<platform name="android" version="3.4.0">
   <plugin name="org...." version="~1.0" />
</platform>

Again though - with npm's JS api, we don't need a package.json to have npm
do the fetching / caching / version checking for us.


On Wed, Apr 9, 2014 at 6:51 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> 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