cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Suggestions for a problem
Date Mon, 07 Apr 2014 23:55:08 GMT
package.json does not iterate any historical data but the npm registry can
be queried or, you know, Git can be


On Tue, Apr 8, 2014 at 11:44 AM, 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