You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Gorkem Ercan <go...@gmail.com> on 2014/04/07 23:00:52 UTC
Suggestions for a problem
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
Re: Suggestions for a problem
Posted by Gorkem Ercan <go...@gmail.com>.
3.4.1 release exists for only iOS and CLI platforms.js is updated to
accordingly so at least it does feel like it is happening.
--
Gorkem
On Mon, Apr 7, 2014 at 3:07 PM, Anis KADRI <an...@gmail.com> wrote:
> Have we actually decided to move along with the plan? I thought we were
> only discussing it.
>
>
> On Mon, Apr 7, 2014 at 2:04 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > We don't know yet because we're still figuring this out.
> >
> > On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan <go...@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
> >
>
Re: Suggestions for a problem
Posted by Steven Gill <st...@gmail.com>.
The plan is to move towards independent releases for platforms.
These are good points Gorkem. Definitely requires more discussion.
On Mon, Apr 7, 2014 at 3:07 PM, Anis KADRI <an...@gmail.com> wrote:
> Have we actually decided to move along with the plan? I thought we were
> only discussing it.
>
>
> On Mon, Apr 7, 2014 at 2:04 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > We don't know yet because we're still figuring this out.
> >
> > On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan <go...@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
> >
>
Re: Suggestions for a problem
Posted by Anis KADRI <an...@gmail.com>.
Have we actually decided to move along with the plan? I thought we were
only discussing it.
On Mon, Apr 7, 2014 at 2:04 PM, Joe Bowser <bo...@gmail.com> wrote:
> We don't know yet because we're still figuring this out.
>
> On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan <go...@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
>
Re: Suggestions for a problem
Posted by Joe Bowser <bo...@gmail.com>.
We don't know yet because we're still figuring this out.
On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan <go...@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
Re: Suggestions for a problem
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Apr 7, 2014 at 8:03 PM, Shazron <sh...@gmail.com> wrote:
> If needed (looks like it is), we should have a highly specific tool (does
> one thing only) that can generate this map automatically. If the data is
>
Is that a stab at coho? ;)
> lacking to do this automatically, my suggestion is to add this meta-data to
> whatever is lacking (plugins, etc).
>
>
> On Mon, Apr 7, 2014 at 3:24 PM, Marcel Kinard <cm...@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 <go...@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
> >
> >
>
Re: Suggestions for a problem
Posted by Shazron <sh...@gmail.com>.
If needed (looks like it is), we should have a highly specific tool (does
one thing only) that can generate this map automatically. If the data is
lacking to do this automatically, my suggestion is to add this meta-data to
whatever is lacking (plugins, etc).
On Mon, Apr 7, 2014 at 3:24 PM, Marcel Kinard <cm...@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 <go...@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
>
>
Re: Suggestions for a problem
Posted by Andrew Grieve <ag...@chromium.org>.
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 <ag...@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 <an...@gmail.com> wrote:
>
>> +1 for platforms in package.json
>>
>>
>> On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams <to...@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" <ag...@chromium.org> wrote:
>> > >
>> > > > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mm...@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 <sh...@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
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Suggestions for a problem
Posted by Andrew Grieve <ag...@chromium.org>.
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 <an...@gmail.com> wrote:
> +1 for platforms in package.json
>
>
> On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams <to...@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" <ag...@chromium.org> wrote:
> > >
> > > > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mm...@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 <sh...@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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Anis KADRI <an...@gmail.com>.
+1 for platforms in package.json
On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams <to...@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" <ag...@chromium.org> wrote:
> >
> > > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <ag...@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 <sh...@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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Tommy Williams <to...@devgeeks.org>.
+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" <ag...@chromium.org> wrote:
>
> > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <ag...@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 <mm...@chromium.org>
> > > > wrote:
> > > > >
> > > > > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Brian LeRoux <b...@brian.io>.
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" <ag...@chromium.org> wrote:
> On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan <go...@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 <mm...@chromium.org>
> > > wrote:
> > > >
> > > > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Andrew Grieve <ag...@chromium.org>.
On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan <go...@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 <mm...@chromium.org>
> > wrote:
> > >
> > > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Michal Mocny <mm...@chromium.org>.
On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan <go...@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?
>
>
> >
> > [1] https://twitter.com/PhoneGapBuild/status/453271589803405313
> >
> > --
> > Gorkem
> >
> >
> >
> > On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Andrew Grieve <ag...@chromium.org>.
On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan <go...@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.
>
> [1] https://twitter.com/PhoneGapBuild/status/453271589803405313
>
> --
> Gorkem
>
>
>
> On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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 <go...@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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Gorkem Ercan <go...@gmail.com>.
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.
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?
[1] https://twitter.com/PhoneGapBuild/status/453271589803405313
--
Gorkem
On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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 <go...@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 <cm...@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 <go...@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
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Apr 7, 2014 at 7:56 PM, Shazron <sh...@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 <go...@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 <cm...@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 <go...@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
> > > >
> > > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Shazron <sh...@gmail.com>.
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 <go...@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 <cm...@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 <go...@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
> > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Brian LeRoux <b...@brian.io>.
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 <go...@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 <cm...@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 <go...@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
> > >
> > >
> >
>
Re: Suggestions for a problem
Posted by Gorkem Ercan <go...@gmail.com>.
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 <cm...@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 <go...@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
> >
> >
>
Re: Suggestions for a problem
Posted by Brian LeRoux <b...@brian.io>.
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 <cm...@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 <go...@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
>
>
Re: Suggestions for a problem
Posted by Marcel Kinard <cm...@gmail.com>.
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 <go...@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