Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CA+X37c=qvQY6yGRMFLNkw5m4SoWMY_1fxK3wMsWRPKEOnKp7BA@mail.gmail.com>
References: 
 <CA+X37cngmCqr+UG2KSJbiib36-0n-yTs-OEvHKjMQD6ukk=beg@mail.gmail.com>
 <2D5891D1-1CC4-4295-BD90-60DDAC99FFF8@gmail.com>
 <CADVgkyOuHd2OB1HafT99NRQAAx=NRv5ynW7mEO2yFhCsbMemOA@mail.gmail.com>
 <CA+X37ckN9KB_jZUznFLi8DM611k8DLn7hm0McTb1+zSSjthm4A@mail.gmail.com>
 <CAE6O_-ZupF9-zv9TjhtWfA4n2t3aWifH6s0sSAMyTRzveLQTDw@mail.gmail.com>
 <CAEeF2TdSUV5gVcLi=e9SQciw_df2r6uNAH8g4wudp4j9jycXPg@mail.gmail.com>
 <CA+X37c=qvQY6yGRMFLNkw5m4SoWMY_1fxK3wMsWRPKEOnKp7BA@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 8 Apr 2014 09:32:05 -0800
Message-ID: 
 <CABiQX1UHDK0CneJskPeraBcQ93J-i6=CdAt2JnzRRhumNa9aSA@mail.gmail.com>
Subject: Re: Suggestions for a problem
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e01229a120f969404f68b5ea8

--089e01229a120f969404f68b5ea8
Content-Type: text/plain; charset=UTF-8

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.


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

--089e01229a120f969404f68b5ea8--