cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Suggestions for a problem
Date Tue, 08 Apr 2014 20:02:08 GMT
On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mmocny@chromium.org> wrote:

> On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan <gorkem.ercan@gmail.com>
> > wrote:
> >
> > > I think a tool can just go through all tagged version of the CLI's
> > > platforms.js and create the version map. I guess this effectively makes
> > CLI
> > > versions the Cordova version.
> > >
> > That's the way I think of it right now as well
> >
> >
> > >
> > > I was looking at the phonegap announcement[1], which got me thinking, I
> > > think independent releases may create complications beyond the problems
> > > like the one I had. For instance take a moment and try to imagine how
> one
> > > would need to write the same announcement for an independent release.
> > >
> > > By the way, I keep hearing that independent platform releases has not
> > > happened yet but since iOS has a 3.4.1 release while all other
> platforms
> > > are 3.4.0 and CLI is getting ready for a release that picks up iOS
> 3.4.1
> > > what else is missing for it to happen?
> > >
> >
> > I think if we get this right, we'd be able to release iOS 3.4.1 *without*
> > having to release a new version of CLI. Just like you don't need to
> update
> > your version of npm when a new version of cordova-cli comes out.
> >
>
> Does this conflict with the previous statement that tooling versions match
> CLI deps?
>

It does. My hope is that eventually the CLI version won't have any mapping
to platform versions. It will just ask npm what the latest version is, and
use that. If users want to pin their versions, they can do so by specifying
the version on the command-line or in their config.xml.

>
>
> >
> >
> > >
> > > [1] https://twitter.com/PhoneGapBuild/status/453271589803405313
> > >
> > > --
> > > Gorkem
> > >
> > >
> > >
> > > On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <shazron@gmail.com> wrote:
> > > >
> > > > > Looks like you will have to generate this yourself for now. But
> > correct
> > > > me
> > > > > if I'm wrong, if the CLI is at version X.Y.Z, wouldn't the platform
> > > > > versions be at least X.Y.Z themselves? At least for the main
> > platforms
> > > > >
> > > >
> > > > I don't think thats what the proposal was, but as Joe says, this
> hasn't
> > > > happened yet and so is still up in the air.
> > > >
> > > > Strictly speaking, if we chose to version everything with semver, the
> > > > version numbers would diverge over time.  The specific x.y.z of one
> > > > artifact would be meaningless when compared to other artifacts, but
> in
> > > > exchange potentially more useful when compared to other versions of
> the
> > > > same artifact.
> > > >
> > > > Implicitly, each release happens on a date, and CLI releases on a
> given
> > > > date depend on the latest releases of each platform.  So, if you have
> > any
> > > > single artifact, you can get the release date, then the corresponding
> > CLI
> > > > release, and finally use that to map backwards to specific semver
> > > versions
> > > > of all platforms.
> > > >
> > > > Personally, though, I'm not sure that we are using Semver to good
> > effect
> > > at
> > > > all, and its just hurting us.  I'd suggest we consider switching to
> > > > versioning by date (aka the Ubuntu / Chromium / etc model).
> > > >
> > > >
> > > > > (android, ios, bb) this would be true I suppose, at least until
> 3.5.0
> > > > (not
> > > > > sure when we are diverging).
> > > > >
> > > > > Since the CLI is tied to certain platform versions, I don't see why
> > the
> > > > map
> > > > > can't be auto generated.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 7, 2014 at 4:44 PM, Gorkem Ercan <
> gorkem.ercan@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Would package.json carry the historical data? At the moment,
my
> > plan
> > > is
> > > > > to
> > > > > > have a json file that maps CLI versions to platform version
but
> for
> > > > every
> > > > > > version > 3.0.0. It would be great if such a file is updated
as
> > part
> > > of
> > > > > the
> > > > > > release of CLI though.
> > > > > > --
> > > > > > Gorkem
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 7, 2014 at 5:07 PM, Brian LeRoux <b@brian.io>
wrote:
> > > > > >
> > > > > > > Moving to independent platform releases doesn't change
things
> > other
> > > > > than
> > > > > > a
> > > > > > > mostly arbitrary number we use for issue tracking. This
is the
> > way
> > > it
> > > > > > works
> > > > > > > today:
> > > > > > >
> > > > > > > CLI@X.X.X
> > > > > > > '- cordova@X.X.X
> > > > > > >     |-ios@X.X.X
> > > > > > >     '-android@X.X.X
> > > > > > >
> > > > > > > This is how it would work in the new world order:
> > > > > > >
> > > > > > > CLI@X.X.X
> > > > > > > |- ios@X.X.X
> > > > > > > '-android@X.X.X
> > > > > > >
> > > > > > > This means other tool that depends on the version locked
> > > convenience
> > > > of
> > > > > > the
> > > > > > > Cordova release basically will want to track whatever we
do
> with
> > > the
> > > > > CLI
> > > > > > > instead. Convienantly we will having this in the Cordova
> > > package.json
> > > > > so,
> > > > > > > hypothetically, this is super easy.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 8, 2014 at 10:24 AM, Marcel Kinard <
> > cmarcelk@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > The way I would summarize this is that enterprises
need a way
> > to
> > > > > > recreate
> > > > > > > > a specific environment. This includes our platforms,
plugins,
> > > > > tooling,
> > > > > > > and
> > > > > > > > dependencies. Many enterprises do not desire to live
on head,
> > > > instead
> > > > > > > they
> > > > > > > > want to live at a known reproductable state. Before
3.0, this
> > was
> > > > > > pretty
> > > > > > > > straightforward. After 3.0, and additionally potentially
> > > releasing
> > > > > > > > platforms separately, our definition of "a Cordova
version"
> has
> > > > > > basically
> > > > > > > > fallen apart (separate timing for plugins and tools,
> > > > > non-shrinkwrapped
> > > > > > > npm
> > > > > > > > dependencies, etc)
> > > > > > > >
> > > > > > > > Perhaps one way to solve this would be a "Cordova
version"
> > > > identifier
> > > > > > > that
> > > > > > > > is a map to the individual versions of all the components,
> > > similar
> > > > to
> > > > > > how
> > > > > > > > cordova-cli/platforms.js has a version property for
each
> > > platform,
> > > > > but
> > > > > > > > include tools and even plugins. How often would it
make sense
> > to
> > > > > update
> > > > > > > > that version-map and bump the Cordova version? There
are
> > probably
> > > > > > > arguments
> > > > > > > > for both a cadence schedule as well as
> > > > anytime-any-component-changes.
> > > > > > > >
> > > > > > > > On Apr 7, 2014, at 5:00 PM, Gorkem Ercan <
> > gorkem.ercan@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > > With the independent platforms releases I have
started to
> run
> > > > into
> > > > > a
> > > > > > > > > problem with my Eclipse tools that I am looking
for some
> > > > > suggestions.
> > > > > > > > >
> > > > > > > > > In the past, Cordova X.Y.Z meant all platforms
would be
> > tagged
> > > > and
> > > > > > > > released
> > > > > > > > > with X.Y.Z. so if Eclipse tools needed to download
Cordova
> > > > version
> > > > > > > X.Y.Z,
> > > > > > > > > it could just do so by using the X.Y.Z git tag.
Now that
> > > > platforms
> > > > > > can
> > > > > > > do
> > > > > > > > > independent releases the X.Y.Z tag for may not
exist for a
> > > > release
> > > > > > for
> > > > > > > a
> > > > > > > > > platform. So I actually need a way to determine
what
> platform
> > > > > > versions
> > > > > > > go
> > > > > > > > > together. CLI actually captures that information
on
> > > platforms.js
> > > > > for
> > > > > > > the
> > > > > > > > > release but this is not enough for Eclipse tools
as it does
> > not
> > > > > > capture
> > > > > > > > the
> > > > > > > > > data for older releases and Eclipse tools can
be download
> and
> > > use
> > > > > > older
> > > > > > > > > versions.
> > > > > > > > >
> > > > > > > > > Is there a place where I can extract this sort
of platform
> > > > version
> > > > > > > > > information?
> > > > > > > > > Also in the past, plugins could define engine
compatibility
> > as
> > > > > below
> > > > > > > > > <engine name="cordova" version="1.7.0" />
> > > > > > > > > How does plugman act with the independent releases
now?
> > > > > > > > > --
> > > > > > > > > Gorkem
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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