Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.214.181 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <85A3E123BABF314D9D3656D0B418125643E4CFE0@FMSMSX103.amr.corp.intel.com>
References: 
 <CAMSbhBj3wHT039EYGdRUpS6T=V8h3S35F0KLp8o-5FchLfFqQQ@mail.gmail.com>
 <CAE6O_-biQLdU+JscPPUrxJ+H3fFZZ3MKOU2Xcg8fb5q848YB5Q@mail.gmail.com>
 <CAMSbhBiVFoLM9ATbxfq-cpYbhZGDsO3vXBVt+Z2AoqmtBtJs+A@mail.gmail.com>
 <CADVgkyPqRTuo9Yjy=TWSgV5QyP-aBwQ2zC3QnFHEMfMkvmSogg@mail.gmail.com>
 <CABiQX1VBCqCYj0bCbuQAULNZ5T=nBUMKAszr=gBYSzurZLvwmA@mail.gmail.com>
 <CABiQX1VVfr6xvv1p0n0R1M2uQnrWGVuxGxTsyivi4_Q4dQXxig@mail.gmail.com>
 <A689F87C-7D9E-4A9D-828E-5341D72361E5@gmail.com>
 <85A3E123BABF314D9D3656D0B418125643E4C17B@FMSMSX103.amr.corp.intel.com>
 <CADVgkyOpAs-DfsdQnS-r1Q4+hNpKfdo0MA4_YR+UTbN=GeRX8w@mail.gmail.com>
 <CABiQX1WxHVUVxDTLEvA4tvW-eEzE-oNZ1eMGe1ZXChnjMYprFg@mail.gmail.com>
 <CADVgkyOd9BXChiFZyh2aXUKiJn9chGkPy5tyepW4VcXosvXqrQ@mail.gmail.com>
 <85A3E123BABF314D9D3656D0B418125643E4C602@FMSMSX103.amr.corp.intel.com>
 <CABiQX1Vtk7c=PVcmaz0qLo-FThJvQBVwn8Uucz5TC5F8beFjdw@mail.gmail.com>
 <85A3E123BABF314D9D3656D0B418125643E4C6F2@FMSMSX103.amr.corp.intel.com>
 <CABiQX1WY+qSxOeKcvK3eWRa8cTb0Mm2DnW04VwhcOR=t26qb_Q@mail.gmail.com>
 <85A3E123BABF314D9D3656D0B418125643E4CFE0@FMSMSX103.amr.corp.intel.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Mon, 6 Oct 2014 15:40:28 -0400
Message-ID: 
 <CABiQX1X4G6TCevKbF4eY+2zamJZpc61dOFGHpmUO9BcVty6nnQ@mail.gmail.com>
Subject: Re: Independent platform release summary
To: "Treggiari, Leo" <leo.treggiari@intel.com>
Cc: Andrew Grieve <agrieve@chromium.org>, Brian LeRoux <b@brian.io>,
	"dev@cordova.apache.org" <dev@cordova.apache.org>,
 Marcel Kinard <cmarcelk@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8ff1ce2278c24a0504c64299

--e89a8ff1ce2278c24a0504c64299
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

To be clear - I think they do stumble. I just don't see a viable path to
make it better.

On Mon, Oct 6, 2014 at 3:22 PM, Treggiari, Leo <leo.treggiari@intel.com>
wrote:

>  Hi Andrew,
>
>
>
> Thanks for reading and responding.  I guess time will tell whether users
> stumble over this or not.
>
>
>
> Leo
>
>
>
> *From:* agrieve@google.com [mailto:agrieve@google.com] *On Behalf Of *And=
rew
> Grieve
> *Sent:* Monday, October 06, 2014 12:12 PM
> *To:* Treggiari, Leo
> *Cc:* Andrew Grieve; Brian LeRoux; dev@cordova.apache.org; Marcel Kinard
>
> *Subject:* Re: Independent platform release summary
>
>
>
> Leo - that was a very well thought out summary of the state of things! I
> agree that from a user perspective, it would be easier to understand and
> reason about things if platform versions corresponded to things that
> platforms support in a x-platform sense.
>
>
>
> I think in practice it's just not feasible to co-ordinate platforms in
> this way. E.g. Android wants to add support for feature X, but iOS is bus=
y
> trying to make iOS 8 work. Should Android disable the feature until it
> rises to the top of the priority list for all other platforms? The answer=
,
> in my opinion, is that we just need to document "feature X works on Andro=
id
> as of FOO, iOS as of BAR"
>
>
>
>
>
> On Sat, Oct 4, 2014 at 4:05 PM, Treggiari, Leo <leo.treggiari@intel.com>
> wrote:
>
>  >To the best of my knowledge, the version numbers of platforms do not
> signify that platforms have the >same functionality. Version numbers for
> plugins also don't really do this - many plugins have different
> >capabilities on different platforms even at the same version number.
>
>
>
> If you tell me that is true then I certainly believe you.  My question is=
,
> is this a good thing?  I.e. Is it the best way to help developers who wan=
t
> to write portable hybrid applications or is it just the way things evolve=
d?
>
>
>
> I just went to http://cordova.apache.org/.  It has a button for =E2=80=9C=
Download
> Cordova version 3.6.0=E2=80=9D.  What mental model should I be using to u=
nderstand
> what I am going to get?  The page also gives me a pointer to the
> documentation - http://cordova.apache.org/docs/en/3.6.0/.
>
>
>
> Note that I=E2=80=99m focusing on the Cross-platform (CLI) workflow.  I c=
urrently
> don=E2=80=99t see why I should care about the Platform-centered workflow.=
  Why?
> Because my own gut, and what I have heard from speakers at conferences,
> tells me that if I=E2=80=99m writing for a single platform, I should stic=
k to the
> native programming environment.  Just an aside to explain where I=E2=80=
=99m coming
> from.
>
>
>
> Some of my statements below could be wrong and please correct me when the=
y
> are.
>
>
>
> Plugins implement the native device functionality.  You point out that
> they can have different capabilities on different platforms.  I understan=
d
> that this must be the case =E2=80=93 i.e. if one platform has a capabilit=
y that
> others don=E2=80=99t, there is no logical reason to make that functionali=
ty
> unavailable until all platforms can support it.  However, if my goal is a
> portable application, I hope this is the exception and not the rule.  As
> long as the documentation clearly points out the platform differences,
> that=E2=80=99s OK.  This is from the first page of the Cordova documentat=
ion:
> =E2=80=9CIdeally, the JavaScript APIs to that native code are consistent =
across
> multiple device platforms.=E2=80=9D  All I can say is 1+.
>
>
>
> What functionality does a Cordova CLI =E2=80=9Cplatform=E2=80=9D provide?
>
> =C2=B7        Cordova =E2=80=9CApplications execute within wrappers targe=
ted to each
> platform=E2=80=9D.  This is clearly platform specific, but to the app dev=
eloper
> this should be =E2=80=9Cinvisible=E2=80=9D.
>
> =C2=B7        Build with a platform SDK which supports a specific set of
> platform versions.  The build functionality should be =E2=80=98opaque=E2=
=80=99 as long as
> the developer has the correct prerequisites correctly installed.  It is
> clearly platform specific as to which version(s) of the platform (OS) a
> Cordova platform supports.
>
> =C2=B7        Supports the functionality specified in config.xml:  =E2=80=
=9CThe
> config.xml file contains important metadata needed to generate and
> distribute the application.=E2=80=9D  The config.xml specification define=
s
> cross-platform configuration options.  I suggest that these cross-platfor=
m
> options defined by a Cordova version (e.g. 3.6) should be supported by al=
l
> platforms that release a 3.6.x version.    Config.xml seems to identify t=
he
> functionality =E2=80=9Ccontract=E2=80=9D for a platform version, over and=
 above the
> wrappers and build functionality which are just assumed to work.  This ma=
y
> already be the case.  Just like with plugin-in APIs, platforms may have
> platform specific functionality.  Again this is OK and should be well
> documented.  Again, when functionality can be abstracted using a common
> paradigm, that helps developers create portable applications more easily.
>
> =C2=B7        Support an embedded WebView:  This seems platform specific =
at
> this time and that is OK.  Maybe it will evolve over time into more
> portable functionality.
>
>
>
> What functionality does Cordova CLI itself provide?  It defines a workflo=
w
> that pulls together plugins and platforms and drives the development
> process for a portable hybrid application.
>
> =C2=B7        Support for platform specific code =E2=80=93 merges
>
> =C2=B7        Support for developer specific workflow additions - hooks
>
> So, should a change in the Cordova CLI version mean a change in the
> workflow functionality?
>
>
>
> Platforms and/or Cordova CLI have a connection to the plugin.xml
> specification, correct?  That is, if a new capability is added to
> plugin.xml, then a newer version of something is required to process it.
> What else have I missed which drives functionality/version changes (leavi=
ng
> out =E2=80=98patch=E2=80=99 versions)?
>
>
>
> Leo
>
>
>
>
>
> *From:* agrieve@google.com [mailto:agrieve@google.com] *On Behalf Of *And=
rew
> Grieve
> *Sent:* Saturday, October 04, 2014 11:05 AM
> *To:* Treggiari, Leo
> *Cc:* Brian LeRoux; Andrew Grieve; dev@cordova.apache.org; Marcel Kinard
>
>
> *Subject:* Re: Independent platform release summary
>
>
>
> To the best of my knowledge, the version numbers of platforms do not
> signify that platforms have the same functionality. Version numbers for
> plugins also don't really do this - many plugins have different
> capabilities on different platforms even at the same version number.
>
>
>
> For example, whitelists mean different things on different platforms.
> Another example is that different platforms added support for ArrayBuffer=
s
> over the exec() bridge at different times. Historically - platform versio=
n
> numbers just mean that they were all released at the same time.
>
>
>
> For the most part, platforms keep changing to keep up with OS changes, bu=
t
> almost never are there features that are added across all platforms at th=
e
> same time.
>
>
>
>
>
>
>
>
>
> On Fri, Oct 3, 2014 at 10:10 PM, Treggiari, Leo <leo.treggiari@intel.com>
> wrote:
>
>  Here=E2=80=99s my concern regarding versions of things in Cordova.  As a
> developer I would use Cordova to write portable applications.  Sure, mayb=
e
> some developers use Cordova for other reasons, but, to me at least, that
> seems to be the primary =E2=80=9Cdraw=E2=80=9D.
>
>
>
> When writing a portable application, I want it to be as easy as possible
> to know that what I want to use is supported everywhere I want to deploy =
my
> app.
>
>
>
> Plugins have independent versions.  That makes sense.  As a developer I
> can see what the API of plugin =E2=80=98FOO=E2=80=99 version =E2=80=98x.y=
.z=E2=80=99 is, and then look at a
> table to see where it is supported.  That answers my questions about APIs
> and how I can use them in a portable manner.
>
>
>
> I want the same to be true of =E2=80=98platform=E2=80=99 and Cordova CLI =
versions as much
> as possible.  Maybe it is true already, but all of these independent
> releases and different platform version numbers make me nervous.  For
> example, If a platform releases version 3.6.0, does that mean that it
> supports the same set of features that other platforms that release 3.6.0
> do?  The major.minor.patch versioning scheme makes a great deal of sense.
> However, imagine all platforms started at version 3.0 with the same set o=
f
> features.  Then 4 separate platforms each added 5 different features in a=
n
> upward compatible manner and so they are now all at version 3.5.0.  How
> does that help our users figure out how they can write a portable
> application?
>
>
>
> Maybe there is a clear definition of what platform version numbers mean
> and I=E2=80=99m just not aware of it.  Maybe a CLI release is not just a =
collection
> of the latest platform releases and I=E2=80=99m just not aware of it.  It=
 makes
> sense that platforms can release asynchronously, but does the versioning
> scheme help the user figure out what is going on and when and where they
> can expect common functionality across platforms?
>
>
>
> Leo
>
>
>
> *From:* brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] *On Behalf
> Of *Brian LeRoux
> *Sent:* Friday, October 03, 2014 5:29 PM
> *To:* Andrew Grieve
> *Cc:* dev@cordova.apache.org; Marcel Kinard; Treggiari, Leo
>
>
> *Subject:* Re: Independent platform release summary
>
>
>
> I meant pinning all platforms to the cli (so an update to any of the
> platforms pushes everything up one). Anyhow this is way hard to reason
> about. So its an improvement how again?
>
> On Oct 3, 2014 4:55 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>
>  Is pinning not what's driving this version number discussion?
>
>
>
> Projects are generally made up of more plugins than platforms, but we
> don't bump the CLI each time plugins are released. Maybe the simplest thi=
ng
> to do is just have the CLI version not be influenced by platform versions
> at all.
>
>
>
> Ideally, we'll finish up the work to write the platform versions in
> config.xml, and then users won't accidentally update their platform
> versions without explicitly doing so in their config.xml (or some
> equivalent CLI command that updates it).
>
>
>
> On Fri, Oct 3, 2014 at 6:02 PM, Brian LeRoux <b@brian.io> wrote:
>
> Maybe pinning platforms and the CLI wasn't so bad after all.
>
> On Oct 3, 2014 2:34 PM, "Treggiari, Leo" <leo.treggiari@intel.com> wrote:
>
> > I agree that this is, and will be, confusing.  It was confusing today i=
n
> > our own discussions in our own team (who are, in general, fairly Cordov=
a
> > savvy) to be talking about the Android store issue related to "Cordova
> > 3.5.1".  E.g. what did it mean to be talking about "Cordova 3.5.1", and
> > what would a user need to do to get the fix?  What I took away was that=
 a
> > user would need  Cordova CLI 3.5.0-0.2.7.  However, I wouldn't be
> surprised
> > if you told me that was wrong...
> >
> > Anyway, a completely different (and possibly immediately dismissible)
> > idea.  What if a Cordova CLI version number was the same as the highest
> > version number of the platforms supported by that Cordova CLI version.
> > E.g. if the latest highest platform version was Android 3.5.1, then the
> > Cordova CLI version would be 3.5.1.  The supported other-platform versi=
on
> > might be lower - e.g. Windows 3.4.2 (totally made up version number...)=
.
> >
> > That doesn't instantly solve all problems.  What if the next platform
> > release after Android 3.5.1 was Windows 3.4.3?  Cordova CLI can't remai=
n
> at
> > the highest version number.  So would Cordova CLI become 3.5.2 or
> 3.5.1-1?
> > Should the Windows release be 3.5.2? Are there a specific set of featur=
es
> > associated with a specific platform major version number?  It seems tha=
t
> a
> > platform release named 3.x.y is expected to have a certain set of
> features
> > implemented.  Is a platform release named 3.4.x expected to have a
> certain
> > set of features and a platform named 3.5.x expected to have those
> features
> > plus some additional feature?
> >
> > In general, what can a user expect these version numbers to mean.  E.g.
> if
> > I as an app developer want to use a particular recently added feature o=
n
> > multiple platforms, how do I determine which versions of which platform=
s
> > support the feature and which Cordova CLI version gives me what I want?
> >
> > Sorry, but it is confusing...
> >
> > Leo
> >
> > -----Original Message-----
> > From: Marcel Kinard [mailto:cmarcelk@gmail.com]
> > Sent: Friday, October 03, 2014 1:56 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Independent platform release summary
> >
> > If a bump to major indicates an API change, how is that visible to user=
s?
> > Do users look at the CLI version as "the version of Cordova", or are we
> > expecting users to look at the version of every Cordova component to
> > understand where majors got bumped? While I agree the latter is more
> > correct technically, I think users have been and are currently assuming
> the
> > former. It would take some education to switch that.
> >
> > On Oct 2, 2014, at 7:51 PM, Andrew Grieve <agrieve@chromium.org> wrote:
> >
> > > I don't think it's necessary to bump CLI major when platforms bump
> major.
> > > Platforms and CLI are linked only superficially anyways.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
>
>
>
>
>
>

--e89a8ff1ce2278c24a0504c64299--