Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of iclelland@google.com
 designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
Sender: iclelland@google.com
In-Reply-To: 
 <CAEeF2TcXc1ZWkb9hhtZB33kZqXrZSy5Gpyxsk9Mvh8SbpZq7NQ@mail.gmail.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>
 <CAEeF2TcXc1ZWkb9hhtZB33kZqXrZSy5Gpyxsk9Mvh8SbpZq7NQ@mail.gmail.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Tue, 7 Oct 2014 08:15:13 -0400
Message-ID: 
 <CAK_TSXLgHtwNsV1mL7T0pZZLizSp7to0p5JxbGT7+61tyvq76A@mail.gmail.com>
Subject: Re: Independent platform release summary
To: Michal Mocny <mmocny@chromium.org>
Cc: "Smith, Peter" <peters@fast.au.fujitsu.com>,
	"dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=e89a8ff1ce22fe2c820504d4278f

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

(b) was mostly made in jest; it definitely fails the "should be
monotonically increasing" test for version numbering schemes :)

(d) is attractive, and we could probably make it work. It would mean that
CLI versions would likely move way ahead of platform versions, but that's
OK. The big change from today is that, instead of telling people to
download "cordova 3.7.0" from npm, we would just say

"Download cordova from npm, and then run 'cordova platform add android@3.7.=
0
'"

So long as the CLI maintains backwards-compatibility with old platforms,
there's never a reason for users to *not* keep updating the CLI in that
case.


On Mon, Oct 6, 2014 at 8:29 PM, Michal Mocny <mmocny@chromium.org> wrote:

> Just got through this thread.  Summarizing Proposals:
>
> (a) CLI moves to v10.0.0, and version numbers increment at same rate as
> (union of) platforms.
>    - This has benefits, but is confusing as shit given our current plan.
> I'm not sure it needs to be this confusing, but we shouldn't make moves
> forward until we think this through some more.
>    - This kinda conflicts with the whole point of independent releases,
> too: a version bump for a platform you don't care about still affects you
> (a bit).
>
> (b) CLI version is a sum of all platform versions
>    - I think this seems an minor management improvement over (a), but fal=
ls
> apart when you consider what happens when you deprecate a platform in the
> future.
>
> (c) We move back to "pinning" platform versions to CLI version (aka, ther=
e
> is a single cordova version number shared by everything)
>    - This conflicts with independant versioning, but maybe not independen=
t
> releases (which is what we are really after).
>    - This implies (I think) releases by date / cadence version, and not
> real semver (Or semver but for the union of all platforms and tools, kind=
a
> pointless).
>    - To do independent platform releases, we should first find a
> lightweight way to bump platform versions without a release (i.e.
> cordova-ios@3.6.0 -> @3.7.0 rename when cordova-android bumps to @3.7.0).
> Otherwise, devs will be upgrading platforms for no reason constantly.
>
> (d) CLI versions completely independent of platforms, just like plugins.
>    - In this case, we need to implement platform->cli version requirement=
s
>  (node peerDependancies?)
>    - Basically means we play down CLI version entirely, users are just
> expected to stay up to date with CLI always.  Platform versions are all
> that matters.  I don't think this is too different than what we have toda=
y.
>
> I personally like (d) most.  Sure, I do like the simplified versioning
> story of (c) (basically cad-ver), but I think its less important now that
> we are doing platform releases to npm.  I hope we won't rely on users
> getting cordova from download links from the website, but rather just npm
> upgrade -g.  I think (a) just complicates (d) needlessly without giving
> real value to users.
>
> Did I make any mistakes?  Shall we meet to discuss this at PGDay US, or
> shall we do a hangout this week if we hope to have something to present t=
o
> the audience in time for PGDay US?
>
> -Michal
>
> On Mon, Oct 6, 2014 at 6: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 committe=
rs
> > is unable to clearly document versioning dependencies then what hope is
> > there for end users to understand it?
> >
> > Peter
> >
> > -----Original Message-----
> > From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andre=
w
> > 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 same 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 at
> the
> > same time.
> >
> >
> >
> >
> > On Fri, Oct 3, 2014 at 10:10 PM, Treggiari, Leo <leo.treggiari@intel.co=
m
> >
> > 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,
> > > maybe 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 tha=
t
> > > 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=E2=80=99m just not aware of it.  Maybe a CLI release is no=
t just a
> > > collection of the latest platform releases and I=E2=80=99m just not a=
ware 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 reaso=
n
> > > 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 platfor=
m
> > > 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 "Cordov=
a
> > > > 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 th=
at
> > 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 CL=
I
> > > > 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 ar=
e
> > > > we expecting users to look at the version of every Cordova componen=
t
> > > > 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 bum=
p
> > > 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
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>

--e89a8ff1ce22fe2c820504d4278f--