cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Independent platform release summary
Date Fri, 03 Oct 2014 01:27:09 GMT
On Thursday, October 2, 2014, Steven Gill <stevengill97@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!
> > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message