cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Suggestions for a problem
Date Tue, 08 Apr 2014 01:24:44 GMT
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