Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of bowserj@gmail.com designates
 209.85.213.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <543365c2.839c420a.4f4b.ffffd0f6@mx.google.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>
	<201DD0641B056142AC8C6645EC1B5F62252EFD28@SYD1217>
	<543365c2.839c420a.4f4b.ffffd0f6@mx.google.com>
Date: Mon, 6 Oct 2014 22:51:02 -0700
Message-ID: 
 <CAOBL_k7ZrRKD2tvW3o+_EFvMc2EJNt1NGTvLsx67yZMwtxVMPw@mail.gmail.com>
Subject: Re: Independent platform release summary
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec51d2064d082d40504cec885

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

I agree with what Jesse said.  That being said, despite talk to the
contrary, I don't think any platform will sprint ahead.  We've never seen
any platform realistically have this happen, especially now that most
features are encapsulated in plugins.

On Mon, Oct 6, 2014 at 9:02 PM, purplecabbage <purplecabbage@gmail.com>
wrote:

> This thread is now out of control, and hopefully this is the signal that
> we need to have a hangout and dig into this.
>
> Thank you Leo for your insight, and representing the user.
>
> The system is elaborately complex, and I fear that
> a) independent versions pushes these platform disparities firmly in the
> users face
> b) the matrix Peter eludes to would have 4 dimensions
>
> I would much rather see all platforms march forwards together, and get th=
e
> version bump regardless of what had changed.
> This way we could at least say 7.5.4 means you get FeatureA for all
> platforms, and FeatureB for platformY,
> If we could get versioning/releasing down to a simple tag-all-repos,
> log-all-changes, update+release all of everything, the system will at lea=
st
> be more understandable. I also think this would make us better at
> releasing, which we currently suck at ( no-one's fault ) I still want to
> release every month, rain or shine, and whether or not we make a big or
> little noise around any release would/could be decided by what made it in=
.
>
> Leo's suggestion, of advancing the CLI version number every time a
> platform updates makes some sense too, if we aren't willing to just tag a=
nd
> release all.
>
> This is a repost, as I apparently only sent this to Peter earlier.
>
> Sent from my iPhone
>
> > On Oct 6, 2014, at 3:37 PM, Smith, Peter <peters@fast.au.fujitsu.com>
> wrote:
> >
> > Super version flexibility =3D=3D Super version confusion.
> >
> > The Cordova site seems in need of a kind of
> Cordova/Platform/CLI/CorePlugin "version dependency matrix" which
> officially documents what-works-with-what (e.g. what has passed the
> official testing). Perhaps it would look something like the API support
> matrix at
> http://cordova.apache.org/docs/en/3.6.0/guide_support_index.md.html#Platf=
orm%20Support
> .
> >
> > It might not be easy to do, but if the combined wit of Cordova
> committers is unable to clearly document versioning dependencies then wha=
t
> hope is there for end users to understand it?
> >
> > Peter
> >
> > -----Original Message-----
> > From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of
> Andrew Grieve
> > Sent: Sunday, 5 October 2014 5: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
> ArrayBuffers over the exec() bridge at different times. Historically -
> platform version numbers just mean that they were all released at the sam=
e
> time.
> >
> > For the most part, platforms keep changing to keep up with OS changes,
> but almost never are there features that are added across all platforms a=
t
> the same time.
> >
> >
> >
> >
> > On Fri, Oct 3, 2014 at 10:10 PM, Treggiari, Leo <leo.treggiari@intel.co=
m
> >
> > wrote:
> >
> >> Here=C3=A2=E2=82=AC=E2=84=A2s my concern regarding versions of things =
in Cordova.  As a
> >> developer I would use Cordova to write portable applications.  Sure,
> >> maybe some developers use Cordova for other reasons, but, to me at
> >> least, that seems to be the primary =C3=A2=E2=82=AC=C5=93draw=C3=A2=E2=
=82=AC .
> >>
> >>
> >>
> >> 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 =C3=A2=E2=82=AC=CB=9CFOO=C3=A2=E2=82=
=AC=E2=84=A2 version =C3=A2=E2=82=AC=CB=9Cx.y.z=C3=A2=E2=82=AC=E2=84=A2 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 =C3=A2=E2=82=AC=CB=9Cplatform=C3=A2=E2=
=82=AC=E2=84=A2 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 of features.  Then 4 separate platforms each added 5 different
> >> features in an 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=C3=A2=E2=82=AC=E2=84=A2m just not aware of it.  Maybe a CLI=
 release is not just a
> >> collection of the latest platform releases and I=C3=A2=E2=82=AC=E2=84=
=A2m 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
> >> thing 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 in our own discussions in our own team (who are, in general,
> >>> fairly Cordova
> >>> 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 version 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 remain
> >> 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
> >>> features associated with a specific platform major version number?
> >>> It seems that
> >> 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 on multiple platforms, how do I determine which versions of
> >>> which platforms 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
> users?
> >>> 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
> >
> B=E2=80=B9KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK=
KKKKKCB=E2=80=A2 =C3=88
> [=C5=93=C3=9DX=C5=93=C3=98=C3=9C=C5=A1X=E2=84=A2K  K[XZ[ =CB=86  ]=E2=80=
=B9][=C5=93=C3=9DX=C5=93=C3=98=C3=9C=C5=A1X=E2=84=A2P =C3=9B=C3=9C=E2=84=A2=
 =C3=9D=CB=9CK=CB=9C\ X=C3=9A K=E2=80=BA=C3=9C=E2=84=A2=C3=83B=E2=80=98=E2=
=80=BA=C3=9C=CB=86 Y  ] [=C3=9B=CB=9C[
> =C3=9B=C3=9B[X[=E2=84=A2 =C3=8B  K[XZ[ =CB=86  ]=E2=80=B9Z [   =C3=9B=C3=
=9C=E2=84=A2 =C3=9D=CB=9CK=CB=9C\ X=C3=9A K=E2=80=BA=C3=9C=E2=84=A2=C3=83B
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

--bcaec51d2064d082d40504cec885--