Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of shazron@gmail.com designates
 209.85.216.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+X37ckN9KB_jZUznFLi8DM611k8DLn7hm0McTb1+zSSjthm4A@mail.gmail.com>
References: 
 <CA+X37cngmCqr+UG2KSJbiib36-0n-yTs-OEvHKjMQD6ukk=beg@mail.gmail.com>
 <2D5891D1-1CC4-4295-BD90-60DDAC99FFF8@gmail.com>
 <CADVgkyOuHd2OB1HafT99NRQAAx=NRv5ynW7mEO2yFhCsbMemOA@mail.gmail.com>
 <CA+X37ckN9KB_jZUznFLi8DM611k8DLn7hm0McTb1+zSSjthm4A@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Mon, 7 Apr 2014 16:56:03 -0700
Message-ID: 
 <CAE6O_-ZupF9-zv9TjhtWfA4n2t3aWifH6s0sSAMyTRzveLQTDw@mail.gmail.com>
Subject: Re: Suggestions for a problem
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11351ce28f109904f67c9e30

--001a11351ce28f109904f67c9e30
Content-Type: text/plain; charset=ISO-8859-1

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
(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
> > >
> > >
> >
>

--001a11351ce28f109904f67c9e30--