You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Steven Gill <st...@gmail.com> on 2014/10/02 20:28:00 UTC
Independent platform release summary
Hey All,
I wanted to give summary of where I believe this process is going and
answer any questions you all might have. None of this is set in stone, so
please provide feedback so we can iron this out.
1) Platforms can now release independently
If iOS wants to release 3.7.0, it doesn't have to wait for other platforms
to be ready to release. Just run through
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
and do a tools release.
2) CLI + Lib version will rise very quickly.
Right now, CLI is about to be released at version 3.7.0. No platforms are
currently at version 3.7.0. Say iOS wants to release 3.7.0 next week, they
could do that, update the CLI to version 3.8.0. I suggest a platform being
released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH ->
3.8.0). But this is obviously open to discussion.
3) Docs
Docs version will now be tied to CLI. If we do a major or minor release of
the CLI, docs should be regenerated to match the version of the CLI. Say
iOS 3.7.0 requires the newest version of the CLI, we can make note of that
in docs + blog post. Maybe we list the platform versions associated to CLI
somewhere in the docs?
4) Helping users debug
Cordova.version & cordova.platformVersion will both return the version of
the platform, not the cli. Users can easily tell you what version of
cordova-platform they are using by doing this. Generated cordova.js files
in projects will also have this information at the top of the file along
with commit hash.
5) Messaging
We need to be clear about this in our messaging to users. This is a change
from how we have been doing things and I foresee some confusion at the
beginning. Moving platforms over to package.json eventually will help users
see that platforms are independent, but we need to do more now to help
users adapt to this change.
They need to know to expect the CLI version to jump quickly, and to know
that platform versions != cordova-cli version.
Blog posts can list platforms cli was tested with, similarly to how we list
what plugin versions the cli was tested with when releasing. (see the
bottom of
http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for an
example)
Hopefully I didn't leave out anything major. Feedback please!
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
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" <ag...@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" <le...@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 <ag...@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
>>> >
>>> >
>>>
>>
>>
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
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 <le...@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 *Andrew
> 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 busy
> 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 Android
> as of FOO, iOS as of BAR"
>
>
>
>
>
> On Sat, Oct 4, 2014 at 4:05 PM, Treggiari, Leo <le...@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 want
> to write portable hybrid applications or is it just the way things evolved?
>
>
>
> I just went to http://cordova.apache.org/. It has a button for “Download
> Cordova version 3.6.0”. What mental model should I be using to understand
> 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’m focusing on the Cross-platform (CLI) workflow. I currently
> don’t 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’m writing for a single platform, I should stick to the
> native programming environment. Just an aside to explain where I’m coming
> from.
>
>
>
> Some of my statements below could be wrong and please correct me when they
> are.
>
>
>
> Plugins implement the native device functionality. You point out that
> they can have different capabilities on different platforms. I understand
> that this must be the case – i.e. if one platform has a capability that
> others don’t, there is no logical reason to make that functionality
> 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’s OK. This is from the first page of the Cordova documentation:
> “Ideally, the JavaScript APIs to that native code are consistent across
> multiple device platforms.” All I can say is 1+.
>
>
>
> What functionality does a Cordova CLI “platform” provide?
>
> · Cordova “Applications execute within wrappers targeted to each
> platform”. This is clearly platform specific, but to the app developer
> this should be “invisible”.
>
> · Build with a platform SDK which supports a specific set of
> platform versions. The build functionality should be ‘opaque’ 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.
>
> · Supports the functionality specified in config.xml: “The
> config.xml file contains important metadata needed to generate and
> distribute the application.” The config.xml specification defines
> cross-platform configuration options. I suggest that these cross-platform
> options defined by a Cordova version (e.g. 3.6) should be supported by all
> platforms that release a 3.6.x version. Config.xml seems to identify the
> functionality “contract” for a platform version, over and above the
> wrappers and build functionality which are just assumed to work. This may
> 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.
>
> · 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 workflow
> that pulls together plugins and platforms and drives the development
> process for a portable hybrid application.
>
> · Support for platform specific code – merges
>
> · 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 (leaving
> out ‘patch’ versions)?
>
>
>
> Leo
>
>
>
>
>
> *From:* agrieve@google.com [mailto:agrieve@google.com] *On Behalf Of *Andrew
> 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 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 <le...@intel.com>
> wrote:
>
> Here’s 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 “draw”.
>
>
>
> 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a collection
> of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> >
> >
>
>
>
>
>
>
>
RE: Independent platform release summary
Posted by "Treggiari, Leo" <le...@intel.com>.
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 Andrew 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 busy 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 Android as of FOO, iOS as of BAR"
On Sat, Oct 4, 2014 at 4:05 PM, Treggiari, Leo <le...@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 want to write portable hybrid applications or is it just the way things evolved?
I just went to http://cordova.apache.org/. It has a button for “Download Cordova version 3.6.0”. What mental model should I be using to understand 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’m focusing on the Cross-platform (CLI) workflow. I currently don’t 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’m writing for a single platform, I should stick to the native programming environment. Just an aside to explain where I’m coming from.
Some of my statements below could be wrong and please correct me when they are.
Plugins implement the native device functionality. You point out that they can have different capabilities on different platforms. I understand that this must be the case – i.e. if one platform has a capability that others don’t, there is no logical reason to make that functionality 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’s OK. This is from the first page of the Cordova documentation: “Ideally, the JavaScript APIs to that native code are consistent across multiple device platforms.” All I can say is 1+.
What functionality does a Cordova CLI “platform” provide?
• Cordova “Applications execute within wrappers targeted to each platform”. This is clearly platform specific, but to the app developer this should be “invisible”.
• Build with a platform SDK which supports a specific set of platform versions. The build functionality should be ‘opaque’ 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.
• Supports the functionality specified in config.xml: “The config.xml file contains important metadata needed to generate and distribute the application.” The config.xml specification defines cross-platform configuration options. I suggest that these cross-platform options defined by a Cordova version (e.g. 3.6) should be supported by all platforms that release a 3.6.x version. Config.xml seems to identify the functionality “contract” for a platform version, over and above the wrappers and build functionality which are just assumed to work. This may 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.
• 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 workflow that pulls together plugins and platforms and drives the development process for a portable hybrid application.
• Support for platform specific code – merges
• 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 (leaving out ‘patch’ versions)?
Leo
From: agrieve@google.com<ma...@google.com> [mailto:agrieve@google.com<ma...@google.com>] On Behalf Of Andrew Grieve
Sent: Saturday, October 04, 2014 11:05 AM
To: Treggiari, Leo
Cc: Brian LeRoux; Andrew Grieve; dev@cordova.apache.org<ma...@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 <le...@intel.com>> wrote:
Here’s 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 “draw”.
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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a collection of the latest platform releases and I’m 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<ma...@gmail.com> [mailto:brian.leroux@gmail.com<ma...@gmail.com>] On Behalf Of Brian LeRoux
Sent: Friday, October 03, 2014 5:29 PM
To: Andrew Grieve
Cc: dev@cordova.apache.org<ma...@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" <ag...@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" <le...@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<ma...@gmail.com>]
> Sent: Friday, October 03, 2014 1:56 PM
> To: dev@cordova.apache.org<ma...@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 <ag...@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<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
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 busy
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 Android
as of FOO, iOS as of BAR"
On Sat, Oct 4, 2014 at 4:05 PM, Treggiari, Leo <le...@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 want
> to write portable hybrid applications or is it just the way things evolved?
>
>
>
> I just went to http://cordova.apache.org/. It has a button for “Download
> Cordova version 3.6.0”. What mental model should I be using to understand
> 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’m focusing on the Cross-platform (CLI) workflow. I currently
> don’t 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’m writing for a single platform, I should stick to the
> native programming environment. Just an aside to explain where I’m coming
> from.
>
>
>
> Some of my statements below could be wrong and please correct me when they
> are.
>
>
>
> Plugins implement the native device functionality. You point out that
> they can have different capabilities on different platforms. I understand
> that this must be the case – i.e. if one platform has a capability that
> others don’t, there is no logical reason to make that functionality
> 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’s OK. This is from the first page of the Cordova documentation:
> “Ideally, the JavaScript APIs to that native code are consistent across
> multiple device platforms.” All I can say is 1+.
>
>
>
> What functionality does a Cordova CLI “platform” provide?
>
> · Cordova “Applications execute within wrappers targeted to each
> platform”. This is clearly platform specific, but to the app developer
> this should be “invisible”.
>
> · Build with a platform SDK which supports a specific set of
> platform versions. The build functionality should be ‘opaque’ 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.
>
> · Supports the functionality specified in config.xml: “The
> config.xml file contains important metadata needed to generate and
> distribute the application.” The config.xml specification defines
> cross-platform configuration options. I suggest that these cross-platform
> options defined by a Cordova version (e.g. 3.6) should be supported by all
> platforms that release a 3.6.x version. Config.xml seems to identify the
> functionality “contract” for a platform version, over and above the
> wrappers and build functionality which are just assumed to work. This may
> 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.
>
> · 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 workflow
> that pulls together plugins and platforms and drives the development
> process for a portable hybrid application.
>
> · Support for platform specific code – merges
>
> · 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 (leaving
> out ‘patch’ versions)?
>
>
>
> Leo
>
>
>
>
>
> *From:* agrieve@google.com [mailto:agrieve@google.com] *On Behalf Of *Andrew
> 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 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 <le...@intel.com>
> wrote:
>
> Here’s 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 “draw”.
>
>
>
> 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a collection
> of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> >
> >
>
>
>
>
>
RE: Independent platform release summary
Posted by "Treggiari, Leo" <le...@intel.com>.
>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 want to write portable hybrid applications or is it just the way things evolved?
I just went to http://cordova.apache.org/. It has a button for “Download Cordova version 3.6.0”. What mental model should I be using to understand 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’m focusing on the Cross-platform (CLI) workflow. I currently don’t 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’m writing for a single platform, I should stick to the native programming environment. Just an aside to explain where I’m coming from.
Some of my statements below could be wrong and please correct me when they are.
Plugins implement the native device functionality. You point out that they can have different capabilities on different platforms. I understand that this must be the case – i.e. if one platform has a capability that others don’t, there is no logical reason to make that functionality 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’s OK. This is from the first page of the Cordova documentation: “Ideally, the JavaScript APIs to that native code are consistent across multiple device platforms.” All I can say is 1+.
What functionality does a Cordova CLI “platform” provide?
· Cordova “Applications execute within wrappers targeted to each platform”. This is clearly platform specific, but to the app developer this should be “invisible”.
· Build with a platform SDK which supports a specific set of platform versions. The build functionality should be ‘opaque’ 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.
· Supports the functionality specified in config.xml: “The config.xml file contains important metadata needed to generate and distribute the application.” The config.xml specification defines cross-platform configuration options. I suggest that these cross-platform options defined by a Cordova version (e.g. 3.6) should be supported by all platforms that release a 3.6.x version. Config.xml seems to identify the functionality “contract” for a platform version, over and above the wrappers and build functionality which are just assumed to work. This may 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.
· 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 workflow that pulls together plugins and platforms and drives the development process for a portable hybrid application.
· Support for platform specific code – merges
· 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 (leaving out ‘patch’ versions)?
Leo
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew 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 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 <le...@intel.com>> wrote:
Here’s 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 “draw”.
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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a collection of the latest platform releases and I’m 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<ma...@gmail.com> [mailto:brian.leroux@gmail.com<ma...@gmail.com>] On Behalf Of Brian LeRoux
Sent: Friday, October 03, 2014 5:29 PM
To: Andrew Grieve
Cc: dev@cordova.apache.org<ma...@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" <ag...@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" <le...@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<ma...@gmail.com>]
> Sent: Friday, October 03, 2014 1:56 PM
> To: dev@cordova.apache.org<ma...@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 <ag...@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<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
Re: Independent platform release summary
Posted by Ian Clelland <ic...@chromium.org>.
(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 <mm...@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 falls
> 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, there
> is a single cordova version number shared by everything)
> - This conflicts with independant versioning, but maybe not independent
> 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, kinda
> 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 requirements
> (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 today.
>
> 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 to
> the audience in time for PGDay US?
>
> -Michal
>
> On Mon, Oct 6, 2014 at 6:37 PM, Smith, Peter <pe...@fast.au.fujitsu.com>
> wrote:
>
> > Super version flexibility == 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#Platform%20Support
> > .
> >
> > It might not be easy to do, but if the combined wit of Cordova committers
> > 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 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 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.com
> >
> > wrote:
> >
> > > Here’s 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 “draw”.
> > >
> > >
> > >
> > > 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
> > > collection of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
RE: Independent platform release summary
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
Getting close.
-Terence
On 10/7/2014 10:15 AM, Treggiari, Leo wrote:
> I think (d) is moving in the right direction but would like to put forth some additional suggestions. I do not have the same level of history and experience with Cordova (usage and implementation) that many of you do, and so it is entirely possible for me to suggest something ridiculous... ;-)
>
> I think a "Cordova release" and it's version number, should be reflected in some component version. E.g. when a user talks about "Cordova 3.5", it's fairly easy to understand, in general, the functionality they have. The details will depend upon the "patch" version number.
>
> So, I would tie the "Cordova version" to the CLI version. In general, the Cordova & CLI version would identify common workflow (CLI) and platform functionality. Common platform functionality is embodied in things like the common entries in config.xml, the default Cordova project (Hello Cordova) etc. This would be what the Cordova version specific documentation would document for the ".0" patch version (e.g. Cordova version 3.6.0).
>
> Plugin version numbers remain completely independent. Platform version numbers are completely independent as well, but it would be helpful if the platform major version number always matched the Cordova major version number. This would mean no incompatible platform functionality changes during the support of a major Cordova version. I don't know if that is realistic. Maybe changes like dropping support for an older platform don't need to require a platform major version number change.
>
> The Cordova and CLI major and minor version numbers increment with changes to the workflow and common platform functionality - e.g. going from 3.5 -> 3.6 added new "whitelist" functionality. Each Cordova release tests with the latest versions of the plugins and latest versions of the platforms.
>
> When a platform releases, regardless of whether it is a major, minor, or patch release, the Cordova and CLI version increments the patch version number. I assume that each Cordova release, including patch releases, defines the default version of each platform which is used when the user adds a platform without a specific version number.
>
> Leo
>
> -----Original Message-----
> From:mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
> Sent: Monday, October 06, 2014 5:29 PM
> To: Smith, Peter
> Cc:dev@cordova.apache.org
> Subject: Re: Independent platform release summary
>
> 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 falls
> 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, there
> is a single cordova version number shared by everything)
> - This conflicts with independant versioning, but maybe not independent
> 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, kinda
> 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 requirements
> (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 today.
>
> 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 to
> the audience in time for PGDay US?
>
> -Michal
>
> On Mon, Oct 6, 2014 at 6:37 PM, Smith, Peter<pe...@fast.au.fujitsu.com>
> wrote:
>
>> >Super version flexibility == 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#Platform%20Support
>> >.
>> >
>> >It might not be easy to do, but if the combined wit of Cordova committers
>> >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 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 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<le...@intel.com>
>> >wrote:
>> >
>>> > > Here’s 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 “draw”.
>>> > >
>>> > >
>>> > >
>>> > >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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
>>> > >collection of the latest platform releases and I’m 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"<ag...@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"<le...@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<ag...@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
>>>> > > >
>>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: Independent platform release summary
Posted by "Treggiari, Leo" <le...@intel.com>.
I think (d) is moving in the right direction but would like to put forth some additional suggestions. I do not have the same level of history and experience with Cordova (usage and implementation) that many of you do, and so it is entirely possible for me to suggest something ridiculous... ;-)
I think a "Cordova release" and it's version number, should be reflected in some component version. E.g. when a user talks about "Cordova 3.5", it's fairly easy to understand, in general, the functionality they have. The details will depend upon the "patch" version number.
So, I would tie the "Cordova version" to the CLI version. In general, the Cordova & CLI version would identify common workflow (CLI) and platform functionality. Common platform functionality is embodied in things like the common entries in config.xml, the default Cordova project (Hello Cordova) etc. This would be what the Cordova version specific documentation would document for the ".0" patch version (e.g. Cordova version 3.6.0).
Plugin version numbers remain completely independent. Platform version numbers are completely independent as well, but it would be helpful if the platform major version number always matched the Cordova major version number. This would mean no incompatible platform functionality changes during the support of a major Cordova version. I don't know if that is realistic. Maybe changes like dropping support for an older platform don't need to require a platform major version number change.
The Cordova and CLI major and minor version numbers increment with changes to the workflow and common platform functionality - e.g. going from 3.5 -> 3.6 added new "whitelist" functionality. Each Cordova release tests with the latest versions of the plugins and latest versions of the platforms.
When a platform releases, regardless of whether it is a major, minor, or patch release, the Cordova and CLI version increments the patch version number. I assume that each Cordova release, including patch releases, defines the default version of each platform which is used when the user adds a platform without a specific version number.
Leo
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Monday, October 06, 2014 5:29 PM
To: Smith, Peter
Cc: dev@cordova.apache.org
Subject: Re: Independent platform release summary
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 falls
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, there
is a single cordova version number shared by everything)
- This conflicts with independant versioning, but maybe not independent
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, kinda
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 requirements
(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 today.
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 to
the audience in time for PGDay US?
-Michal
On Mon, Oct 6, 2014 at 6:37 PM, Smith, Peter <pe...@fast.au.fujitsu.com>
wrote:
> Super version flexibility == 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#Platform%20Support
> .
>
> It might not be easy to do, but if the combined wit of Cordova committers
> 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 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 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 <le...@intel.com>
> wrote:
>
> > Here’s 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 “draw”.
> >
> >
> >
> > 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
> > collection of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> > >
> > >
> >
> >
> >
> >
>
Re: Independent platform release summary
Posted by Michal Mocny <mm...@chromium.org>.
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 falls
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, there
is a single cordova version number shared by everything)
- This conflicts with independant versioning, but maybe not independent
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, kinda
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 requirements
(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 today.
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 to
the audience in time for PGDay US?
-Michal
On Mon, Oct 6, 2014 at 6:37 PM, Smith, Peter <pe...@fast.au.fujitsu.com>
wrote:
> Super version flexibility == 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#Platform%20Support
> .
>
> It might not be easy to do, but if the combined wit of Cordova committers
> 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 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 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 <le...@intel.com>
> wrote:
>
> > Here’s 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 “draw”.
> >
> >
> >
> > 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
> > collection of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> > >
> > >
> >
> >
> >
> >
>
Re: Independent platform release summary
Posted by Joe Bowser <bo...@gmail.com>.
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 <pu...@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 the
> 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 least
> 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 and
> 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 <pe...@fast.au.fujitsu.com>
> wrote:
> >
> > Super version flexibility == 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#Platform%20Support
> .
> >
> > It might not be easy to do, but if the combined wit of Cordova
> committers 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
> 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 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.com
> >
> > wrote:
> >
> >> Here’s 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 “draw†.
> >>
> >>
> >>
> >> 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
> >> collection of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB• È
> [œÝXœØÜšX™K K[XZ[ ˆ ]‹][œÝXœØÜšX™P ÛÜ™ ݘK˜\ XÚ K›Ü™ÃB‘›Üˆ Y ] [Û˜[
> ÛÛ[X[™ Ë K[XZ[ ˆ ]‹Z [ ÛÜ™ ݘK˜\ XÚ K›Ü™ÃB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Independent platform release summary
Posted by purplecabbage <pu...@gmail.com>.
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 the 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 least 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 and 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 <pe...@fast.au.fujitsu.com> wrote:
>
> Super version flexibility == 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#Platform%20Support.
>
> It might not be easy to do, but if the combined wit of Cordova committers 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 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 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 <le...@intel.com>
> wrote:
>
>> Here’s 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 “drawâ€.
>>
>>
>>
>> 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
>> collection of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PÛܙݘK˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ ÛܙݘK˜\XÚK›Ü™ÃB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: Independent platform release summary
Posted by "Smith, Peter" <pe...@fast.au.fujitsu.com>.
Super version flexibility == 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#Platform%20Support.
It might not be easy to do, but if the combined wit of Cordova committers 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 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 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 <le...@intel.com>
wrote:
> Here’s 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 “draw”.
>
>
>
> 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a
> collection of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> >
> >
>
>
>
>
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
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 <le...@intel.com>
wrote:
> Here’s 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 “draw”.
>
>
>
> 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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a collection
> of the latest platform releases and I’m 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" <ag...@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" <le...@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 <ag...@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
> >
> >
>
>
>
>
RE: Independent platform release summary
Posted by "Treggiari, Leo" <le...@intel.com>.
Here’s 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 “draw”.
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 ‘FOO’ version ‘x.y.z’ 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 ‘platform’ 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’m just not aware of it. Maybe a CLI release is not just a collection of the latest platform releases and I’m 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" <ag...@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" <le...@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<ma...@gmail.com>]
> Sent: Friday, October 03, 2014 1:56 PM
> To: dev@cordova.apache.org<ma...@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 <ag...@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<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
Re: Independent platform release summary
Posted by Brian LeRoux <b...@brian.io>.
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" <ag...@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" <le...@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 <ag...@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
>> >
>> >
>>
>
>
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
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" <le...@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 <ag...@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
> >
> >
>
Re: Independent platform release summary
Posted by Marcel Kinard <cm...@gmail.com>.
+1
On Oct 3, 2014, at 8:05 PM, Steven Gill <st...@gmail.com> wrote:
> Looking through peoples responses on this thread and the project version thread, many people have been pushing for a bigger jump in version number for the CLI.
>
> Chatting with Shaz, he is very concerned about support issues coming in with users being very confused about versions. By having a big seperation between platform versions and cli version, that will at least remove the connection between the two.
>
> I'm leaning towards a bigger jump now.
>
> Proposal: CLI becomes version 10.0.0
P.S.: The "10" suggestion was halfway in jest, to match BlackBerry, OS X, Node, and Windows. But the other half was serious. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Independent platform release summary
Posted by Steven Gill <st...@gmail.com>.
Looking through peoples responses on this thread and the project version
thread, many people have been pushing for a bigger jump in version number
for the CLI.
Chatting with Shaz, he is very concerned about support issues coming in
with users being very confused about versions. By having a big seperation
between platform versions and cli version, that will at least remove the
connection between the two.
I'm leaning towards a bigger jump now.
Proposal: CLI becomes version 10.0.0
On Fri, Oct 3, 2014 at 3: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" <le...@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 <ag...@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
> >
> >
>
RE: Independent platform release summary
Posted by Brian LeRoux <b...@brian.io>.
Maybe pinning platforms and the CLI wasn't so bad after all.
On Oct 3, 2014 2:34 PM, "Treggiari, Leo" <le...@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 <ag...@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
>
>
RE: Independent platform release summary
Posted by "Treggiari, Leo" <le...@intel.com>.
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 <ag...@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
Re: Independent platform release summary
Posted by Marcel Kinard <cm...@gmail.com>.
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 <ag...@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
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Oct 2, 2014 at 8:12 PM, Steven Gill <st...@gmail.com> wrote:
> Thanks for feedback!
>
> I like the idea of giving our early adopters a chance to try it out and
> help us catch bugs, but I think that should be what RCs are for (3 day
> window while voting is ongoing).
>
> How do we handle cases where the bump in platform is accompanied by a
> change in cordova-lib. The next iOS release has this. Anyone who wants the
> next iOS release will have to update their cli. If they do cordova platform
> add cordova-ios@nextRelease, they will run into issues with their version
> of cordova-lib not supporting the changes required. (Shaz can elaborate if
> you need, something about new splashscreen support). We have no way of
> preventing older cli users from trying to install newer ios other than
> documentation and blog post.
>
Maybe have a minCordovaLibVersion setting in cordova-ios's package.json?
>
> Obviously, my above example isn't a usecase that happens every release. My
> goal here is to try and find a versioning policy that is easy to follow and
> covers as many use cases as possible. It should also follow semver.
>
>
> Also, noticed I had an error in my examples (the writing was fine though).
>
> CLI + Lib versioning (imagine version for cli + lib is at 4.0.0):
>
> if a platform does a patch version jump (ex ios 3.6.1), then cli + lib
> should do a patch jump (ex 4.0.1)
> If a platform does a minor version jump (ex ios 3.7.0), then cli + lib
> should do a minor jump (ex 4.1.0)
> If a platform does a major version jump (ex android 4.0.0), then cli + lib
> should do a major jump. (ex up to 5.0.0)
>
>
>
>
> On Thu, Oct 2, 2014 at 4:51 PM, Andrew Grieve <ag...@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.
>>
>> What do you think about:
>> 1. Release platform
>> 2. Blog post telling people to try it out using CLI platform
>> add@new_version
>> 3. After a week, bump the default platform install in CLI (the week gives
>> some blog-post-following early adopters time to catch any mess-ups)
>>
>> On Thu, Oct 2, 2014 at 7:46 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>>> Great write-up! Totally onboard. And like the suggestion of bumping the
>>> major (I say either 4.0 or 10.0).
>>>
>>> On Thu, Oct 2, 2014 at 3:58 PM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>>> I'm down with jumping to 4.x but not convinced a jump to 5.x would
>>>> actually
>>>> spur more understanding. (Also thanks for tackling this Steve.)
>>>>
>>>> On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com>
>>>> wrote:
>>>>
>>>> > I'm not opposed to a big version jump. It would draw attention to the
>>>> fact
>>>> > that we are changing our versioning & releasing process. How do others
>>>> > feel?
>>>> >
>>>> > -Steve
>>>> >
>>>> > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
>>>> >
>>>> > > Thanks Steve for writing that up.
>>>> > > I can definitely see the confusion in messaging, especially at the
>>>> start
>>>> > > of this new process.
>>>> > >
>>>> > > So for "2) CLI + Lib version" I am proposing a radical idea (à la
>>>> Windows
>>>> > > 10) where we jump to a new version totally separate from the
>>>> current 3.x
>>>> > > series to further detach the association of the CLI version with
>>>> platform
>>>> > > versions. Version 5.x? Not sure how sem-ver kosher it is.
>>>> > >
>>>> > > I already have one scenario. I sent out pull requests for docs and
>>>> the
>>>> > CLI
>>>> > > for the new iPhone 6 icons and splash screens. These will be in the
>>>> next
>>>> > > iOS platform release 3.7.0, and if another platform didn't take
>>>> 3.8.0
>>>> > > already, most likely CLI 3.8.0.
>>>> > >
>>>> > > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
>>>> cordova-ios
>>>> > > will be at 3.7.0. This is how the messaging will look like if I
>>>> were to
>>>> > > write a blog post:
>>>> > > "To get cordova-cli support for iPhone 6 splash screens and icons,
>>>> please
>>>> > > update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
>>>> > > cordova-ios where this feature is implemented. Check out the 3.8.0
>>>> > > cordova-docs for usage". A bit clunky.
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <
>>>> stevengill97@gmail.com>
>>>> > > wrote:
>>>> > >
>>>> > >> Hey All,
>>>> > >>
>>>> > >> I wanted to give summary of where I believe this process is going
>>>> and
>>>> > >> answer any questions you all might have. None of this is set in
>>>> stone,
>>>> > so
>>>> > >> please provide feedback so we can iron this out.
>>>> > >>
>>>> > >> 1) Platforms can now release independently
>>>> > >>
>>>> > >> If iOS wants to release 3.7.0, it doesn't have to wait for other
>>>> > platforms
>>>> > >> to be ready to release. Just run through
>>>> > >>
>>>> > >>
>>>> >
>>>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>>>> > >> and do a tools release.
>>>> > >>
>>>> > >> 2) CLI + Lib version will rise very quickly.
>>>> > >>
>>>> > >> Right now, CLI is about to be released at version 3.7.0. No
>>>> platforms
>>>> > are
>>>> > >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next
>>>> week,
>>>> > they
>>>> > >> could do that, update the CLI to version 3.8.0. I suggest a
>>>> platform
>>>> > being
>>>> > >> released would cause the CLI to do a minor release
>>>> (MAJOR.MINOR.PATCH ->
>>>> > >> 3.8.0). But this is obviously open to discussion.
>>>> > >>
>>>> > >> 3) Docs
>>>> > >>
>>>> > >> Docs version will now be tied to CLI. If we do a major or minor
>>>> release
>>>> > of
>>>> > >> the CLI, docs should be regenerated to match the version of the
>>>> CLI. Say
>>>> > >> iOS 3.7.0 requires the newest version of the CLI, we can make note
>>>> of
>>>> > that
>>>> > >> in docs + blog post. Maybe we list the platform versions
>>>> associated to
>>>> > CLI
>>>> > >> somewhere in the docs?
>>>> > >>
>>>> > >> 4) Helping users debug
>>>> > >>
>>>> > >> Cordova.version & cordova.platformVersion will both return the
>>>> version
>>>> > of
>>>> > >> the platform, not the cli. Users can easily tell you what version
>>>> of
>>>> > >> cordova-platform they are using by doing this. Generated cordova.js
>>>> > files
>>>> > >> in projects will also have this information at the top of the file
>>>> along
>>>> > >> with commit hash.
>>>> > >>
>>>> > >> 5) Messaging
>>>> > >>
>>>> > >> We need to be clear about this in our messaging to users. This is a
>>>> > change
>>>> > >> from how we have been doing things and I foresee some confusion at
>>>> the
>>>> > >> beginning. Moving platforms over to package.json eventually will
>>>> help
>>>> > >> users
>>>> > >> see that platforms are independent, but we need to do more now to
>>>> help
>>>> > >> users adapt to this change.
>>>> > >>
>>>> > >> They need to know to expect the CLI version to jump quickly, and
>>>> to know
>>>> > >> that platform versions != cordova-cli version.
>>>> > >>
>>>> > >> Blog posts can list platforms cli was tested with, similarly to
>>>> how we
>>>> > >> list
>>>> > >> what plugin versions the cli was tested with when releasing. (see
>>>> the
>>>> > >> bottom of
>>>> > >>
>>>> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for
>>>> > >> an
>>>> > >> example)
>>>> > >>
>>>> > >> Hopefully I didn't leave out anything major. Feedback please!
>>>> > >>
>>>> > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: Independent platform release summary
Posted by Steven Gill <st...@gmail.com>.
Thanks for feedback!
I like the idea of giving our early adopters a chance to try it out and
help us catch bugs, but I think that should be what RCs are for (3 day
window while voting is ongoing).
How do we handle cases where the bump in platform is accompanied by a
change in cordova-lib. The next iOS release has this. Anyone who wants the
next iOS release will have to update their cli. If they do cordova platform
add cordova-ios@nextRelease, they will run into issues with their version
of cordova-lib not supporting the changes required. (Shaz can elaborate if
you need, something about new splashscreen support). We have no way of
preventing older cli users from trying to install newer ios other than
documentation and blog post.
Obviously, my above example isn't a usecase that happens every release. My
goal here is to try and find a versioning policy that is easy to follow and
covers as many use cases as possible. It should also follow semver.
Also, noticed I had an error in my examples (the writing was fine though).
CLI + Lib versioning (imagine version for cli + lib is at 4.0.0):
if a platform does a patch version jump (ex ios 3.6.1), then cli + lib
should do a patch jump (ex 4.0.1)
If a platform does a minor version jump (ex ios 3.7.0), then cli + lib
should do a minor jump (ex 4.1.0)
If a platform does a major version jump (ex android 4.0.0), then cli + lib
should do a major jump. (ex up to 5.0.0)
On Thu, Oct 2, 2014 at 4:51 PM, Andrew Grieve <ag...@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.
>
> What do you think about:
> 1. Release platform
> 2. Blog post telling people to try it out using CLI platform
> add@new_version
> 3. After a week, bump the default platform install in CLI (the week gives
> some blog-post-following early adopters time to catch any mess-ups)
>
> On Thu, Oct 2, 2014 at 7:46 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
>> Great write-up! Totally onboard. And like the suggestion of bumping the
>> major (I say either 4.0 or 10.0).
>>
>> On Thu, Oct 2, 2014 at 3:58 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> I'm down with jumping to 4.x but not convinced a jump to 5.x would
>>> actually
>>> spur more understanding. (Also thanks for tackling this Steve.)
>>>
>>> On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com>
>>> wrote:
>>>
>>> > I'm not opposed to a big version jump. It would draw attention to the
>>> fact
>>> > that we are changing our versioning & releasing process. How do others
>>> > feel?
>>> >
>>> > -Steve
>>> >
>>> > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
>>> >
>>> > > Thanks Steve for writing that up.
>>> > > I can definitely see the confusion in messaging, especially at the
>>> start
>>> > > of this new process.
>>> > >
>>> > > So for "2) CLI + Lib version" I am proposing a radical idea (à la
>>> Windows
>>> > > 10) where we jump to a new version totally separate from the current
>>> 3.x
>>> > > series to further detach the association of the CLI version with
>>> platform
>>> > > versions. Version 5.x? Not sure how sem-ver kosher it is.
>>> > >
>>> > > I already have one scenario. I sent out pull requests for docs and
>>> the
>>> > CLI
>>> > > for the new iPhone 6 icons and splash screens. These will be in the
>>> next
>>> > > iOS platform release 3.7.0, and if another platform didn't take 3.8.0
>>> > > already, most likely CLI 3.8.0.
>>> > >
>>> > > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
>>> cordova-ios
>>> > > will be at 3.7.0. This is how the messaging will look like if I were
>>> to
>>> > > write a blog post:
>>> > > "To get cordova-cli support for iPhone 6 splash screens and icons,
>>> please
>>> > > update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
>>> > > cordova-ios where this feature is implemented. Check out the 3.8.0
>>> > > cordova-docs for usage". A bit clunky.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <stevengill97@gmail.com
>>> >
>>> > > wrote:
>>> > >
>>> > >> Hey All,
>>> > >>
>>> > >> I wanted to give summary of where I believe this process is going
>>> and
>>> > >> answer any questions you all might have. None of this is set in
>>> stone,
>>> > so
>>> > >> please provide feedback so we can iron this out.
>>> > >>
>>> > >> 1) Platforms can now release independently
>>> > >>
>>> > >> If iOS wants to release 3.7.0, it doesn't have to wait for other
>>> > platforms
>>> > >> to be ready to release. Just run through
>>> > >>
>>> > >>
>>> >
>>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>>> > >> and do a tools release.
>>> > >>
>>> > >> 2) CLI + Lib version will rise very quickly.
>>> > >>
>>> > >> Right now, CLI is about to be released at version 3.7.0. No
>>> platforms
>>> > are
>>> > >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next
>>> week,
>>> > they
>>> > >> could do that, update the CLI to version 3.8.0. I suggest a platform
>>> > being
>>> > >> released would cause the CLI to do a minor release
>>> (MAJOR.MINOR.PATCH ->
>>> > >> 3.8.0). But this is obviously open to discussion.
>>> > >>
>>> > >> 3) Docs
>>> > >>
>>> > >> Docs version will now be tied to CLI. If we do a major or minor
>>> release
>>> > of
>>> > >> the CLI, docs should be regenerated to match the version of the
>>> CLI. Say
>>> > >> iOS 3.7.0 requires the newest version of the CLI, we can make note
>>> of
>>> > that
>>> > >> in docs + blog post. Maybe we list the platform versions associated
>>> to
>>> > CLI
>>> > >> somewhere in the docs?
>>> > >>
>>> > >> 4) Helping users debug
>>> > >>
>>> > >> Cordova.version & cordova.platformVersion will both return the
>>> version
>>> > of
>>> > >> the platform, not the cli. Users can easily tell you what version of
>>> > >> cordova-platform they are using by doing this. Generated cordova.js
>>> > files
>>> > >> in projects will also have this information at the top of the file
>>> along
>>> > >> with commit hash.
>>> > >>
>>> > >> 5) Messaging
>>> > >>
>>> > >> We need to be clear about this in our messaging to users. This is a
>>> > change
>>> > >> from how we have been doing things and I foresee some confusion at
>>> the
>>> > >> beginning. Moving platforms over to package.json eventually will
>>> help
>>> > >> users
>>> > >> see that platforms are independent, but we need to do more now to
>>> help
>>> > >> users adapt to this change.
>>> > >>
>>> > >> They need to know to expect the CLI version to jump quickly, and to
>>> know
>>> > >> that platform versions != cordova-cli version.
>>> > >>
>>> > >> Blog posts can list platforms cli was tested with, similarly to how
>>> we
>>> > >> list
>>> > >> what plugin versions the cli was tested with when releasing. (see
>>> the
>>> > >> bottom of
>>> > >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html
>>> for
>>> > >> an
>>> > >> example)
>>> > >>
>>> > >> Hopefully I didn't leave out anything major. Feedback please!
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
I don't think it's necessary to bump CLI major when platforms bump major.
Platforms and CLI are linked only superficially anyways.
What do you think about:
1. Release platform
2. Blog post telling people to try it out using CLI platform add@new_version
3. After a week, bump the default platform install in CLI (the week gives
some blog-post-following early adopters time to catch any mess-ups)
On Thu, Oct 2, 2014 at 7:46 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Great write-up! Totally onboard. And like the suggestion of bumping the
> major (I say either 4.0 or 10.0).
>
> On Thu, Oct 2, 2014 at 3:58 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> I'm down with jumping to 4.x but not convinced a jump to 5.x would
>> actually
>> spur more understanding. (Also thanks for tackling this Steve.)
>>
>> On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com>
>> wrote:
>>
>> > I'm not opposed to a big version jump. It would draw attention to the
>> fact
>> > that we are changing our versioning & releasing process. How do others
>> > feel?
>> >
>> > -Steve
>> >
>> > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > Thanks Steve for writing that up.
>> > > I can definitely see the confusion in messaging, especially at the
>> start
>> > > of this new process.
>> > >
>> > > So for "2) CLI + Lib version" I am proposing a radical idea (à la
>> Windows
>> > > 10) where we jump to a new version totally separate from the current
>> 3.x
>> > > series to further detach the association of the CLI version with
>> platform
>> > > versions. Version 5.x? Not sure how sem-ver kosher it is.
>> > >
>> > > I already have one scenario. I sent out pull requests for docs and the
>> > CLI
>> > > for the new iPhone 6 icons and splash screens. These will be in the
>> next
>> > > iOS platform release 3.7.0, and if another platform didn't take 3.8.0
>> > > already, most likely CLI 3.8.0.
>> > >
>> > > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
>> cordova-ios
>> > > will be at 3.7.0. This is how the messaging will look like if I were
>> to
>> > > write a blog post:
>> > > "To get cordova-cli support for iPhone 6 splash screens and icons,
>> please
>> > > update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
>> > > cordova-ios where this feature is implemented. Check out the 3.8.0
>> > > cordova-docs for usage". A bit clunky.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <st...@gmail.com>
>> > > wrote:
>> > >
>> > >> Hey All,
>> > >>
>> > >> I wanted to give summary of where I believe this process is going and
>> > >> answer any questions you all might have. None of this is set in
>> stone,
>> > so
>> > >> please provide feedback so we can iron this out.
>> > >>
>> > >> 1) Platforms can now release independently
>> > >>
>> > >> If iOS wants to release 3.7.0, it doesn't have to wait for other
>> > platforms
>> > >> to be ready to release. Just run through
>> > >>
>> > >>
>> >
>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>> > >> and do a tools release.
>> > >>
>> > >> 2) CLI + Lib version will rise very quickly.
>> > >>
>> > >> Right now, CLI is about to be released at version 3.7.0. No platforms
>> > are
>> > >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next week,
>> > they
>> > >> could do that, update the CLI to version 3.8.0. I suggest a platform
>> > being
>> > >> released would cause the CLI to do a minor release
>> (MAJOR.MINOR.PATCH ->
>> > >> 3.8.0). But this is obviously open to discussion.
>> > >>
>> > >> 3) Docs
>> > >>
>> > >> Docs version will now be tied to CLI. If we do a major or minor
>> release
>> > of
>> > >> the CLI, docs should be regenerated to match the version of the CLI.
>> Say
>> > >> iOS 3.7.0 requires the newest version of the CLI, we can make note of
>> > that
>> > >> in docs + blog post. Maybe we list the platform versions associated
>> to
>> > CLI
>> > >> somewhere in the docs?
>> > >>
>> > >> 4) Helping users debug
>> > >>
>> > >> Cordova.version & cordova.platformVersion will both return the
>> version
>> > of
>> > >> the platform, not the cli. Users can easily tell you what version of
>> > >> cordova-platform they are using by doing this. Generated cordova.js
>> > files
>> > >> in projects will also have this information at the top of the file
>> along
>> > >> with commit hash.
>> > >>
>> > >> 5) Messaging
>> > >>
>> > >> We need to be clear about this in our messaging to users. This is a
>> > change
>> > >> from how we have been doing things and I foresee some confusion at
>> the
>> > >> beginning. Moving platforms over to package.json eventually will help
>> > >> users
>> > >> see that platforms are independent, but we need to do more now to
>> help
>> > >> users adapt to this change.
>> > >>
>> > >> They need to know to expect the CLI version to jump quickly, and to
>> know
>> > >> that platform versions != cordova-cli version.
>> > >>
>> > >> Blog posts can list platforms cli was tested with, similarly to how
>> we
>> > >> list
>> > >> what plugin versions the cli was tested with when releasing. (see the
>> > >> bottom of
>> > >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html
>> for
>> > >> an
>> > >> example)
>> > >>
>> > >> Hopefully I didn't leave out anything major. Feedback please!
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: Independent platform release summary
Posted by Andrew Grieve <ag...@chromium.org>.
Great write-up! Totally onboard. And like the suggestion of bumping the
major (I say either 4.0 or 10.0).
On Thu, Oct 2, 2014 at 3:58 PM, Brian LeRoux <b...@brian.io> wrote:
> I'm down with jumping to 4.x but not convinced a jump to 5.x would actually
> spur more understanding. (Also thanks for tackling this Steve.)
>
> On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> > I'm not opposed to a big version jump. It would draw attention to the
> fact
> > that we are changing our versioning & releasing process. How do others
> > feel?
> >
> > -Steve
> >
> > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > Thanks Steve for writing that up.
> > > I can definitely see the confusion in messaging, especially at the
> start
> > > of this new process.
> > >
> > > So for "2) CLI + Lib version" I am proposing a radical idea (à la
> Windows
> > > 10) where we jump to a new version totally separate from the current
> 3.x
> > > series to further detach the association of the CLI version with
> platform
> > > versions. Version 5.x? Not sure how sem-ver kosher it is.
> > >
> > > I already have one scenario. I sent out pull requests for docs and the
> > CLI
> > > for the new iPhone 6 icons and splash screens. These will be in the
> next
> > > iOS platform release 3.7.0, and if another platform didn't take 3.8.0
> > > already, most likely CLI 3.8.0.
> > >
> > > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
> cordova-ios
> > > will be at 3.7.0. This is how the messaging will look like if I were to
> > > write a blog post:
> > > "To get cordova-cli support for iPhone 6 splash screens and icons,
> please
> > > update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
> > > cordova-ios where this feature is implemented. Check out the 3.8.0
> > > cordova-docs for usage". A bit clunky.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <st...@gmail.com>
> > > wrote:
> > >
> > >> Hey All,
> > >>
> > >> I wanted to give summary of where I believe this process is going and
> > >> answer any questions you all might have. None of this is set in stone,
> > so
> > >> please provide feedback so we can iron this out.
> > >>
> > >> 1) Platforms can now release independently
> > >>
> > >> If iOS wants to release 3.7.0, it doesn't have to wait for other
> > platforms
> > >> to be ready to release. Just run through
> > >>
> > >>
> >
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
> > >> and do a tools release.
> > >>
> > >> 2) CLI + Lib version will rise very quickly.
> > >>
> > >> Right now, CLI is about to be released at version 3.7.0. No platforms
> > are
> > >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next week,
> > they
> > >> could do that, update the CLI to version 3.8.0. I suggest a platform
> > being
> > >> released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH
> ->
> > >> 3.8.0). But this is obviously open to discussion.
> > >>
> > >> 3) Docs
> > >>
> > >> Docs version will now be tied to CLI. If we do a major or minor
> release
> > of
> > >> the CLI, docs should be regenerated to match the version of the CLI.
> Say
> > >> iOS 3.7.0 requires the newest version of the CLI, we can make note of
> > that
> > >> in docs + blog post. Maybe we list the platform versions associated to
> > CLI
> > >> somewhere in the docs?
> > >>
> > >> 4) Helping users debug
> > >>
> > >> Cordova.version & cordova.platformVersion will both return the version
> > of
> > >> the platform, not the cli. Users can easily tell you what version of
> > >> cordova-platform they are using by doing this. Generated cordova.js
> > files
> > >> in projects will also have this information at the top of the file
> along
> > >> with commit hash.
> > >>
> > >> 5) Messaging
> > >>
> > >> We need to be clear about this in our messaging to users. This is a
> > change
> > >> from how we have been doing things and I foresee some confusion at the
> > >> beginning. Moving platforms over to package.json eventually will help
> > >> users
> > >> see that platforms are independent, but we need to do more now to help
> > >> users adapt to this change.
> > >>
> > >> They need to know to expect the CLI version to jump quickly, and to
> know
> > >> that platform versions != cordova-cli version.
> > >>
> > >> Blog posts can list platforms cli was tested with, similarly to how we
> > >> list
> > >> what plugin versions the cli was tested with when releasing. (see the
> > >> bottom of
> > >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html
> for
> > >> an
> > >> example)
> > >>
> > >> Hopefully I didn't leave out anything major. Feedback please!
> > >>
> > >
> > >
> >
>
Re: Independent platform release summary
Posted by Ian Clelland <ic...@chromium.org>.
On Thursday, October 2, 2014, Steven Gill <st...@gmail.com> wrote:
> We would have to restart the tools vote to change the version.
>
> I don't see much difference from jumping to 4.0 compared to 5.0 or 10.0
It's entirely psychological. A big jump is just leaving the older
versioning further behind.
> Higher version jump would be to build some separation between platforms
> versions and cli version. Even if we go to 4.0, Cordova version jumps will
> be frequent and rapid.
>
> I personally think it makes more sense to make the version jump now then
> later. I'm not to inclined to tie a major version jump to a conference but
> rather when it feels right due to our versioning policies.
Agreed. Conference-based-versioning would be an odd standard to have to
hold ourselves to :)
>
> Below is a overview of how I see versioning.
>
> Semver summary
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> 1. MAJOR version when you make incompatible API changes,
> 2. MINOR version when you add functionality in a backwards-compatible
> manner, and
> 3. PATCH version when you make backwards-compatible bug fixes.
>
> My proposal:
>
> CLI + Lib versioning (imagine version for cli + lib is at 4.0.0):
>
> if a platform does a patch version jump (ex ios 3.7.1), then cli + lib
> should do a patch jump (ex 4.0.1)
> If a platform does a minor version jump (ex ios 3.7.0), then cli + lib
> should do a minor jump (ex 4.0.1)
> If a platform does a major version jump (ex android 4.0.0), then cli + lib
> should do a major jump. (ex up to 5.0.0)
I was thinking this when I was reading your first email in the thread. I
think it makes sense.
Interestingly, it also means that we could legitimately give the tools
release a version which is the *sum* of all of the platforms included :)
>
> Platform versioning:
>
> Introduce any breaking changes, bump major
> Regular releases, bump minor
> Small fixes, bump patch
>
> Questions for platforms:
All my opinions:
>
> 1) What happens when cordova-iOS adds support for iOS8? (3.7.0 or 4.0.0)
Minor version bump
2) What happens when cordova-iOS drops support for iOS6?
Major version bump
> 3) How do we ensure we have common functionality between different
> platforms? When we went from 2.x to 3.x, all platforms had to have similar
> subset of features. If cordova-android is at version 7.0.0, cordova-ios at
> 5.0.0, cordova-firefoxos at 3.7.0, how do keep track of this? Is being tied
> to a specific CLI version with docs enough?
This is harder, especially if platforms don't all get the feature at the
same time. I would suggest that we solve it with documentation.
4) Windows adds universal app support, what is the version for
> cordova-windows?
Minor version bump
> 5) Windows supports windows 10, what is the version?
Minor bump
>
>
> Plugin Versioning
>
> Non backwards compatible change, bump major
> Adding new api/feature, keeping backwards compatibility, bumb minor
> Small bug fixes, Most of our regular releases, bump patch
Sounds about right!
There's some interplay between plugins and platforms as well: when a
feature is added to one platform in one version, and then to a second
platform in another version. I suppose it's two minor bumps in that case,
but I'd want to be careful to avoid the analogous situation where we have
to have two, three, or more major bumps in a row because of out-of-sync
platform-specific changes.
>
>
> Feedback please!
>
>
>
>
>
> On Thu, Oct 2, 2014 at 1:48 PM, Parashuram Narasimhan (MS OPEN TECH) <
> panarasi@microsoft.com <javascript:;>> wrote:
>
> > Would jumping to 4.x mean we have to re-tag restart the vote process?
> > Traditionally, Cordova has had major version bump close to Phonegap day -
> > If we continue this to be 3.7.0, will we have another release close to
> > Phonegap day, calling that 4.0 ?
> >
> > -----Original Message-----
> > From: brian.leroux@gmail.com <javascript:;> [mailto:
> brian.leroux@gmail.com <javascript:;>] On Behalf Of
> > Brian LeRoux
> > Sent: Thursday, October 2, 2014 12:58 PM
> > To: Steven Gill
> > Cc: Shazron; dev@cordova.apache.org <javascript:;>
> > Subject: Re: Independent platform release summary
> >
> > I'm down with jumping to 4.x but not convinced a jump to 5.x would
> > actually spur more understanding. (Also thanks for tackling this Steve.)
> >
> > On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <stevengill97@gmail.com
> <javascript:;>>
> > wrote:
> >
> > > I'm not opposed to a big version jump. It would draw attention to the
> > > fact that we are changing our versioning & releasing process. How do
> > > others feel?
> > >
> > > -Steve
> > >
> > > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <shazron@gmail.com
> <javascript:;>> wrote:
> > >
> > > > Thanks Steve for writing that up.
> > > > I can definitely see the confusion in messaging, especially at the
> > > > start of this new process.
> > > >
> > > > So for "2) CLI + Lib version" I am proposing a radical idea (à la
> > > > Windows
> > > > 10) where we jump to a new version totally separate from the current
> > > > 3.x series to further detach the association of the CLI version with
> > > > platform versions. Version 5.x? Not sure how sem-ver kosher it is.
> > > >
> > > > I already have one scenario. I sent out pull requests for docs and
> > > > the
> > > CLI
> > > > for the new iPhone 6 icons and splash screens. These will be in the
> > > > next iOS platform release 3.7.0, and if another platform didn't take
> > > > 3.8.0 already, most likely CLI 3.8.0.
> > > >
> > > > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
> > > > cordova-ios will be at 3.7.0. This is how the messaging will look
> > > > like if I were to write a blog post:
> > > > "To get cordova-cli support for iPhone 6 splash screens and icons,
> > > > please update to cordova-cli 3.8.0, which will grab the 3.7.0
> > > > version of cordova-ios where this feature is implemented. Check out
> > > > the 3.8.0 cordova-docs for usage". A bit clunky.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill
> > > > <stevengill97@gmail.com <javascript:;>>
> > > > wrote:
> > > >
> > > >> Hey All,
> > > >>
> > > >> I wanted to give summary of where I believe this process is going
> > > >> and answer any questions you all might have. None of this is set in
> > > >> stone,
> > > so
> > > >> please provide feedback so we can iron this out.
> > > >>
> > > >> 1) Platforms can now release independently
> > > >>
> > > >> If iOS wants to release 3.7.0, it doesn't have to wait for other
> > > platforms
> > > >> to be ready to release. Just run through
> > > >>
> > > >>
> > > https://github.com/apache/cordova-coho/blob/master/docs/platforms-rele
> > > ase-process.md
> > > >> and do a tools release.
> > > >>
> > > >> 2) CLI + Lib version will rise very quickly.
> > > >>
> > > >> Right now, CLI is about to be released at version 3.7.0. No
> > > >> platforms
> > > are
> > > >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next
> > > >> week,
> > > they
> > > >> could do that, update the CLI to version 3.8.0. I suggest a
> > > >> platform
> > > being
> > > >> released would cause the CLI to do a minor release
> > > >> (MAJOR.MINOR.PATCH -> 3.8.0). But this is obviously open to
> > discussion.
> > > >>
> > > >> 3) Docs
> > > >>
> > > >> Docs version will now be tied to CLI. If we do a major or minor
> > > >> release
> > > of
> > > >> the CLI, docs should be regenerated to match the version of the
> > > >> CLI. Say iOS 3.7.0 requires the newest version of the CLI, we can
> > > >> make note of
> > > that
> > > >> in docs + blog post. Maybe we list the platform versions associated
> > > >> to
> > > CLI
> > > >> somewhere in the docs?
> > > >>
> > > >> 4) Helping users debug
> > > >>
> > > >> Cordova.version & cordova.platformVersion will both return the
> > > >> version
> > > of
> > > >> the platform, not the cli. Users can easily tell you what version
> > > >> of cordova-platform they are using by doing this. Generated
> > > >> cordova.js
> > > files
> > > >> in projects will also have this information at the top of the file
> > > >> along with commit hash.
> > > >>
> > > >> 5) Messaging
> > > >>
> > > >> We need to be clear about this in our messaging to users. This is a
> > > change
> > > >> from how we have been doing things and I foresee some confusion at
> > > >> the beginning. Moving platforms over to package.json eventually
> > > >> will help users see that platforms are independent, but we need to
> > > >> do more now to help users adapt to this change.
> > > >>
> > > >> They need to know to expect the CLI version to jump quickly, and to
> > > >> know that platform versions != cordova-cli version.
> > > >>
> > > >> Blog posts can list platforms cli was tested with, similarly to how
> > > >> we list what plugin versions the cli was tested with when
> > > >> releasing. (see the bottom of
> > > >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html
> > > >> for an
> > > >> example)
> > > >>
> > > >> Hopefully I didn't leave out anything major. Feedback please!
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Independent platform release summary
Posted by Steven Gill <st...@gmail.com>.
We would have to restart the tools vote to change the version.
I don't see much difference from jumping to 4.0 compared to 5.0 or 10.0
Higher version jump would be to build some separation between platforms
versions and cli version. Even if we go to 4.0, Cordova version jumps will
be frequent and rapid.
I personally think it makes more sense to make the version jump now then
later. I'm not to inclined to tie a major version jump to a conference but
rather when it feels right due to our versioning policies.
Below is a overview of how I see versioning.
Semver summary
Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible
manner, and
3. PATCH version when you make backwards-compatible bug fixes.
My proposal:
CLI + Lib versioning (imagine version for cli + lib is at 4.0.0):
if a platform does a patch version jump (ex ios 3.7.1), then cli + lib
should do a patch jump (ex 4.0.1)
If a platform does a minor version jump (ex ios 3.7.0), then cli + lib
should do a minor jump (ex 4.0.1)
If a platform does a major version jump (ex android 4.0.0), then cli + lib
should do a major jump. (ex up to 5.0.0)
Platform versioning:
Introduce any breaking changes, bump major
Regular releases, bump minor
Small fixes, bump patch
Questions for platforms:
1) What happens when cordova-iOS adds support for iOS8? (3.7.0 or 4.0.0)
2) What happens when cordova-iOS drops support for iOS6?
3) How do we ensure we have common functionality between different
platforms? When we went from 2.x to 3.x, all platforms had to have similar
subset of features. If cordova-android is at version 7.0.0, cordova-ios at
5.0.0, cordova-firefoxos at 3.7.0, how do keep track of this? Is being tied
to a specific CLI version with docs enough?
4) Windows adds universal app support, what is the version for
cordova-windows?
5) Windows supports windows 10, what is the version?
Plugin Versioning
Non backwards compatible change, bump major
Adding new api/feature, keeping backwards compatibility, bumb minor
Small bug fixes, Most of our regular releases, bump patch
Feedback please!
On Thu, Oct 2, 2014 at 1:48 PM, Parashuram Narasimhan (MS OPEN TECH) <
panarasi@microsoft.com> wrote:
> Would jumping to 4.x mean we have to re-tag restart the vote process?
> Traditionally, Cordova has had major version bump close to Phonegap day -
> If we continue this to be 3.7.0, will we have another release close to
> Phonegap day, calling that 4.0 ?
>
> -----Original Message-----
> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: Thursday, October 2, 2014 12:58 PM
> To: Steven Gill
> Cc: Shazron; dev@cordova.apache.org
> Subject: Re: Independent platform release summary
>
> I'm down with jumping to 4.x but not convinced a jump to 5.x would
> actually spur more understanding. (Also thanks for tackling this Steve.)
>
> On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> > I'm not opposed to a big version jump. It would draw attention to the
> > fact that we are changing our versioning & releasing process. How do
> > others feel?
> >
> > -Steve
> >
> > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > Thanks Steve for writing that up.
> > > I can definitely see the confusion in messaging, especially at the
> > > start of this new process.
> > >
> > > So for "2) CLI + Lib version" I am proposing a radical idea (à la
> > > Windows
> > > 10) where we jump to a new version totally separate from the current
> > > 3.x series to further detach the association of the CLI version with
> > > platform versions. Version 5.x? Not sure how sem-ver kosher it is.
> > >
> > > I already have one scenario. I sent out pull requests for docs and
> > > the
> > CLI
> > > for the new iPhone 6 icons and splash screens. These will be in the
> > > next iOS platform release 3.7.0, and if another platform didn't take
> > > 3.8.0 already, most likely CLI 3.8.0.
> > >
> > > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
> > > cordova-ios will be at 3.7.0. This is how the messaging will look
> > > like if I were to write a blog post:
> > > "To get cordova-cli support for iPhone 6 splash screens and icons,
> > > please update to cordova-cli 3.8.0, which will grab the 3.7.0
> > > version of cordova-ios where this feature is implemented. Check out
> > > the 3.8.0 cordova-docs for usage". A bit clunky.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill
> > > <st...@gmail.com>
> > > wrote:
> > >
> > >> Hey All,
> > >>
> > >> I wanted to give summary of where I believe this process is going
> > >> and answer any questions you all might have. None of this is set in
> > >> stone,
> > so
> > >> please provide feedback so we can iron this out.
> > >>
> > >> 1) Platforms can now release independently
> > >>
> > >> If iOS wants to release 3.7.0, it doesn't have to wait for other
> > platforms
> > >> to be ready to release. Just run through
> > >>
> > >>
> > https://github.com/apache/cordova-coho/blob/master/docs/platforms-rele
> > ase-process.md
> > >> and do a tools release.
> > >>
> > >> 2) CLI + Lib version will rise very quickly.
> > >>
> > >> Right now, CLI is about to be released at version 3.7.0. No
> > >> platforms
> > are
> > >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next
> > >> week,
> > they
> > >> could do that, update the CLI to version 3.8.0. I suggest a
> > >> platform
> > being
> > >> released would cause the CLI to do a minor release
> > >> (MAJOR.MINOR.PATCH -> 3.8.0). But this is obviously open to
> discussion.
> > >>
> > >> 3) Docs
> > >>
> > >> Docs version will now be tied to CLI. If we do a major or minor
> > >> release
> > of
> > >> the CLI, docs should be regenerated to match the version of the
> > >> CLI. Say iOS 3.7.0 requires the newest version of the CLI, we can
> > >> make note of
> > that
> > >> in docs + blog post. Maybe we list the platform versions associated
> > >> to
> > CLI
> > >> somewhere in the docs?
> > >>
> > >> 4) Helping users debug
> > >>
> > >> Cordova.version & cordova.platformVersion will both return the
> > >> version
> > of
> > >> the platform, not the cli. Users can easily tell you what version
> > >> of cordova-platform they are using by doing this. Generated
> > >> cordova.js
> > files
> > >> in projects will also have this information at the top of the file
> > >> along with commit hash.
> > >>
> > >> 5) Messaging
> > >>
> > >> We need to be clear about this in our messaging to users. This is a
> > change
> > >> from how we have been doing things and I foresee some confusion at
> > >> the beginning. Moving platforms over to package.json eventually
> > >> will help users see that platforms are independent, but we need to
> > >> do more now to help users adapt to this change.
> > >>
> > >> They need to know to expect the CLI version to jump quickly, and to
> > >> know that platform versions != cordova-cli version.
> > >>
> > >> Blog posts can list platforms cli was tested with, similarly to how
> > >> we list what plugin versions the cli was tested with when
> > >> releasing. (see the bottom of
> > >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html
> > >> for an
> > >> example)
> > >>
> > >> Hopefully I didn't leave out anything major. Feedback please!
> > >>
> > >
> > >
> >
>
RE: Independent platform release summary
Posted by "Parashuram Narasimhan (MS OPEN TECH)" <pa...@microsoft.com>.
Would jumping to 4.x mean we have to re-tag restart the vote process?
Traditionally, Cordova has had major version bump close to Phonegap day - If we continue this to be 3.7.0, will we have another release close to Phonegap day, calling that 4.0 ?
-----Original Message-----
From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of Brian LeRoux
Sent: Thursday, October 2, 2014 12:58 PM
To: Steven Gill
Cc: Shazron; dev@cordova.apache.org
Subject: Re: Independent platform release summary
I'm down with jumping to 4.x but not convinced a jump to 5.x would actually spur more understanding. (Also thanks for tackling this Steve.)
On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com> wrote:
> I'm not opposed to a big version jump. It would draw attention to the
> fact that we are changing our versioning & releasing process. How do
> others feel?
>
> -Steve
>
> On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
>
> > Thanks Steve for writing that up.
> > I can definitely see the confusion in messaging, especially at the
> > start of this new process.
> >
> > So for "2) CLI + Lib version" I am proposing a radical idea (à la
> > Windows
> > 10) where we jump to a new version totally separate from the current
> > 3.x series to further detach the association of the CLI version with
> > platform versions. Version 5.x? Not sure how sem-ver kosher it is.
> >
> > I already have one scenario. I sent out pull requests for docs and
> > the
> CLI
> > for the new iPhone 6 icons and splash screens. These will be in the
> > next iOS platform release 3.7.0, and if another platform didn't take
> > 3.8.0 already, most likely CLI 3.8.0.
> >
> > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but
> > cordova-ios will be at 3.7.0. This is how the messaging will look
> > like if I were to write a blog post:
> > "To get cordova-cli support for iPhone 6 splash screens and icons,
> > please update to cordova-cli 3.8.0, which will grab the 3.7.0
> > version of cordova-ios where this feature is implemented. Check out
> > the 3.8.0 cordova-docs for usage". A bit clunky.
> >
> >
> >
> >
> >
> > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill
> > <st...@gmail.com>
> > wrote:
> >
> >> Hey All,
> >>
> >> I wanted to give summary of where I believe this process is going
> >> and answer any questions you all might have. None of this is set in
> >> stone,
> so
> >> please provide feedback so we can iron this out.
> >>
> >> 1) Platforms can now release independently
> >>
> >> If iOS wants to release 3.7.0, it doesn't have to wait for other
> platforms
> >> to be ready to release. Just run through
> >>
> >>
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-rele
> ase-process.md
> >> and do a tools release.
> >>
> >> 2) CLI + Lib version will rise very quickly.
> >>
> >> Right now, CLI is about to be released at version 3.7.0. No
> >> platforms
> are
> >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next
> >> week,
> they
> >> could do that, update the CLI to version 3.8.0. I suggest a
> >> platform
> being
> >> released would cause the CLI to do a minor release
> >> (MAJOR.MINOR.PATCH -> 3.8.0). But this is obviously open to discussion.
> >>
> >> 3) Docs
> >>
> >> Docs version will now be tied to CLI. If we do a major or minor
> >> release
> of
> >> the CLI, docs should be regenerated to match the version of the
> >> CLI. Say iOS 3.7.0 requires the newest version of the CLI, we can
> >> make note of
> that
> >> in docs + blog post. Maybe we list the platform versions associated
> >> to
> CLI
> >> somewhere in the docs?
> >>
> >> 4) Helping users debug
> >>
> >> Cordova.version & cordova.platformVersion will both return the
> >> version
> of
> >> the platform, not the cli. Users can easily tell you what version
> >> of cordova-platform they are using by doing this. Generated
> >> cordova.js
> files
> >> in projects will also have this information at the top of the file
> >> along with commit hash.
> >>
> >> 5) Messaging
> >>
> >> We need to be clear about this in our messaging to users. This is a
> change
> >> from how we have been doing things and I foresee some confusion at
> >> the beginning. Moving platforms over to package.json eventually
> >> will help users see that platforms are independent, but we need to
> >> do more now to help users adapt to this change.
> >>
> >> They need to know to expect the CLI version to jump quickly, and to
> >> know that platform versions != cordova-cli version.
> >>
> >> Blog posts can list platforms cli was tested with, similarly to how
> >> we list what plugin versions the cli was tested with when
> >> releasing. (see the bottom of
> >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html
> >> for an
> >> example)
> >>
> >> Hopefully I didn't leave out anything major. Feedback please!
> >>
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Independent platform release summary
Posted by Brian LeRoux <b...@brian.io>.
I'm down with jumping to 4.x but not convinced a jump to 5.x would actually
spur more understanding. (Also thanks for tackling this Steve.)
On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <st...@gmail.com> wrote:
> I'm not opposed to a big version jump. It would draw attention to the fact
> that we are changing our versioning & releasing process. How do others
> feel?
>
> -Steve
>
> On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
>
> > Thanks Steve for writing that up.
> > I can definitely see the confusion in messaging, especially at the start
> > of this new process.
> >
> > So for "2) CLI + Lib version" I am proposing a radical idea (à la Windows
> > 10) where we jump to a new version totally separate from the current 3.x
> > series to further detach the association of the CLI version with platform
> > versions. Version 5.x? Not sure how sem-ver kosher it is.
> >
> > I already have one scenario. I sent out pull requests for docs and the
> CLI
> > for the new iPhone 6 icons and splash screens. These will be in the next
> > iOS platform release 3.7.0, and if another platform didn't take 3.8.0
> > already, most likely CLI 3.8.0.
> >
> > This would mean the docs would be at 3.8.0, CLI at 3.8.0 but cordova-ios
> > will be at 3.7.0. This is how the messaging will look like if I were to
> > write a blog post:
> > "To get cordova-cli support for iPhone 6 splash screens and icons, please
> > update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
> > cordova-ios where this feature is implemented. Check out the 3.8.0
> > cordova-docs for usage". A bit clunky.
> >
> >
> >
> >
> >
> > On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <st...@gmail.com>
> > wrote:
> >
> >> Hey All,
> >>
> >> I wanted to give summary of where I believe this process is going and
> >> answer any questions you all might have. None of this is set in stone,
> so
> >> please provide feedback so we can iron this out.
> >>
> >> 1) Platforms can now release independently
> >>
> >> If iOS wants to release 3.7.0, it doesn't have to wait for other
> platforms
> >> to be ready to release. Just run through
> >>
> >>
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
> >> and do a tools release.
> >>
> >> 2) CLI + Lib version will rise very quickly.
> >>
> >> Right now, CLI is about to be released at version 3.7.0. No platforms
> are
> >> currently at version 3.7.0. Say iOS wants to release 3.7.0 next week,
> they
> >> could do that, update the CLI to version 3.8.0. I suggest a platform
> being
> >> released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH ->
> >> 3.8.0). But this is obviously open to discussion.
> >>
> >> 3) Docs
> >>
> >> Docs version will now be tied to CLI. If we do a major or minor release
> of
> >> the CLI, docs should be regenerated to match the version of the CLI. Say
> >> iOS 3.7.0 requires the newest version of the CLI, we can make note of
> that
> >> in docs + blog post. Maybe we list the platform versions associated to
> CLI
> >> somewhere in the docs?
> >>
> >> 4) Helping users debug
> >>
> >> Cordova.version & cordova.platformVersion will both return the version
> of
> >> the platform, not the cli. Users can easily tell you what version of
> >> cordova-platform they are using by doing this. Generated cordova.js
> files
> >> in projects will also have this information at the top of the file along
> >> with commit hash.
> >>
> >> 5) Messaging
> >>
> >> We need to be clear about this in our messaging to users. This is a
> change
> >> from how we have been doing things and I foresee some confusion at the
> >> beginning. Moving platforms over to package.json eventually will help
> >> users
> >> see that platforms are independent, but we need to do more now to help
> >> users adapt to this change.
> >>
> >> They need to know to expect the CLI version to jump quickly, and to know
> >> that platform versions != cordova-cli version.
> >>
> >> Blog posts can list platforms cli was tested with, similarly to how we
> >> list
> >> what plugin versions the cli was tested with when releasing. (see the
> >> bottom of
> >> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for
> >> an
> >> example)
> >>
> >> Hopefully I didn't leave out anything major. Feedback please!
> >>
> >
> >
>
Re: Independent platform release summary
Posted by Steven Gill <st...@gmail.com>.
I'm not opposed to a big version jump. It would draw attention to the fact
that we are changing our versioning & releasing process. How do others feel?
-Steve
On Thu, Oct 2, 2014 at 11:45 AM, Shazron <sh...@gmail.com> wrote:
> Thanks Steve for writing that up.
> I can definitely see the confusion in messaging, especially at the start
> of this new process.
>
> So for "2) CLI + Lib version" I am proposing a radical idea (à la Windows
> 10) where we jump to a new version totally separate from the current 3.x
> series to further detach the association of the CLI version with platform
> versions. Version 5.x? Not sure how sem-ver kosher it is.
>
> I already have one scenario. I sent out pull requests for docs and the CLI
> for the new iPhone 6 icons and splash screens. These will be in the next
> iOS platform release 3.7.0, and if another platform didn't take 3.8.0
> already, most likely CLI 3.8.0.
>
> This would mean the docs would be at 3.8.0, CLI at 3.8.0 but cordova-ios
> will be at 3.7.0. This is how the messaging will look like if I were to
> write a blog post:
> "To get cordova-cli support for iPhone 6 splash screens and icons, please
> update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
> cordova-ios where this feature is implemented. Check out the 3.8.0
> cordova-docs for usage". A bit clunky.
>
>
>
>
>
> On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <st...@gmail.com>
> wrote:
>
>> Hey All,
>>
>> I wanted to give summary of where I believe this process is going and
>> answer any questions you all might have. None of this is set in stone, so
>> please provide feedback so we can iron this out.
>>
>> 1) Platforms can now release independently
>>
>> If iOS wants to release 3.7.0, it doesn't have to wait for other platforms
>> to be ready to release. Just run through
>>
>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>> and do a tools release.
>>
>> 2) CLI + Lib version will rise very quickly.
>>
>> Right now, CLI is about to be released at version 3.7.0. No platforms are
>> currently at version 3.7.0. Say iOS wants to release 3.7.0 next week, they
>> could do that, update the CLI to version 3.8.0. I suggest a platform being
>> released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH ->
>> 3.8.0). But this is obviously open to discussion.
>>
>> 3) Docs
>>
>> Docs version will now be tied to CLI. If we do a major or minor release of
>> the CLI, docs should be regenerated to match the version of the CLI. Say
>> iOS 3.7.0 requires the newest version of the CLI, we can make note of that
>> in docs + blog post. Maybe we list the platform versions associated to CLI
>> somewhere in the docs?
>>
>> 4) Helping users debug
>>
>> Cordova.version & cordova.platformVersion will both return the version of
>> the platform, not the cli. Users can easily tell you what version of
>> cordova-platform they are using by doing this. Generated cordova.js files
>> in projects will also have this information at the top of the file along
>> with commit hash.
>>
>> 5) Messaging
>>
>> We need to be clear about this in our messaging to users. This is a change
>> from how we have been doing things and I foresee some confusion at the
>> beginning. Moving platforms over to package.json eventually will help
>> users
>> see that platforms are independent, but we need to do more now to help
>> users adapt to this change.
>>
>> They need to know to expect the CLI version to jump quickly, and to know
>> that platform versions != cordova-cli version.
>>
>> Blog posts can list platforms cli was tested with, similarly to how we
>> list
>> what plugin versions the cli was tested with when releasing. (see the
>> bottom of
>> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for
>> an
>> example)
>>
>> Hopefully I didn't leave out anything major. Feedback please!
>>
>
>
Re: Independent platform release summary
Posted by Shazron <sh...@gmail.com>.
Thanks Steve for writing that up.
I can definitely see the confusion in messaging, especially at the start of
this new process.
So for "2) CLI + Lib version" I am proposing a radical idea (à la Windows
10) where we jump to a new version totally separate from the current 3.x
series to further detach the association of the CLI version with platform
versions. Version 5.x? Not sure how sem-ver kosher it is.
I already have one scenario. I sent out pull requests for docs and the CLI
for the new iPhone 6 icons and splash screens. These will be in the next
iOS platform release 3.7.0, and if another platform didn't take 3.8.0
already, most likely CLI 3.8.0.
This would mean the docs would be at 3.8.0, CLI at 3.8.0 but cordova-ios
will be at 3.7.0. This is how the messaging will look like if I were to
write a blog post:
"To get cordova-cli support for iPhone 6 splash screens and icons, please
update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
cordova-ios where this feature is implemented. Check out the 3.8.0
cordova-docs for usage". A bit clunky.
On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <st...@gmail.com> wrote:
> Hey All,
>
> I wanted to give summary of where I believe this process is going and
> answer any questions you all might have. None of this is set in stone, so
> please provide feedback so we can iron this out.
>
> 1) Platforms can now release independently
>
> If iOS wants to release 3.7.0, it doesn't have to wait for other platforms
> to be ready to release. Just run through
>
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
> and do a tools release.
>
> 2) CLI + Lib version will rise very quickly.
>
> Right now, CLI is about to be released at version 3.7.0. No platforms are
> currently at version 3.7.0. Say iOS wants to release 3.7.0 next week, they
> could do that, update the CLI to version 3.8.0. I suggest a platform being
> released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH ->
> 3.8.0). But this is obviously open to discussion.
>
> 3) Docs
>
> Docs version will now be tied to CLI. If we do a major or minor release of
> the CLI, docs should be regenerated to match the version of the CLI. Say
> iOS 3.7.0 requires the newest version of the CLI, we can make note of that
> in docs + blog post. Maybe we list the platform versions associated to CLI
> somewhere in the docs?
>
> 4) Helping users debug
>
> Cordova.version & cordova.platformVersion will both return the version of
> the platform, not the cli. Users can easily tell you what version of
> cordova-platform they are using by doing this. Generated cordova.js files
> in projects will also have this information at the top of the file along
> with commit hash.
>
> 5) Messaging
>
> We need to be clear about this in our messaging to users. This is a change
> from how we have been doing things and I foresee some confusion at the
> beginning. Moving platforms over to package.json eventually will help users
> see that platforms are independent, but we need to do more now to help
> users adapt to this change.
>
> They need to know to expect the CLI version to jump quickly, and to know
> that platform versions != cordova-cli version.
>
> Blog posts can list platforms cli was tested with, similarly to how we list
> what plugin versions the cli was tested with when releasing. (see the
> bottom of
> http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for an
> example)
>
> Hopefully I didn't leave out anything major. Feedback please!
>