Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.218.43 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CADVgkyOd9BXChiFZyh2aXUKiJn9chGkPy5tyepW4VcXosvXqrQ@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>
From: Andrew Grieve <agrieve@chromium.org>
Date: Sat, 4 Oct 2014 14:06:10 -0400
Message-ID: 
 <CABiQX1Vqg+ZrbJ1w+E1XPXxFTx8ahnMnCfWgYNOUWXtckHswJQ@mail.gmail.com>
Subject: Re: Independent platform release summary
To: Brian LeRoux <b@brian.io>
Cc: Andrew Grieve <agrieve@chromium.org>, dev <dev@cordova.apache.org>,
	Marcel Kinard <cmarcelk@gmail.com>, Leo Treggiari <leo.treggiari@intel.com>
Content-Type: multipart/alternative; boundary=001a113310008e13d605049cb562

--001a113310008e13d605049cb562
Content-Type: text/plain; charset=UTF-8

Still not clear what you're trying to convey here. What's the
alternative(s) to linking platform versions with CLI versions?

On Fri, Oct 3, 2014 at 8:28 PM, Brian LeRoux <b@brian.io> wrote:

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

--001a113310008e13d605049cb562--