cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Independent platform release summary
Date Thu, 02 Oct 2014 22:14:37 GMT
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 <stevengill97@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 <shazron@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-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