Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of stevengill97@gmail.com
 designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABiQX1XrzH0nzVE6gRYE9vNaxS0AP+pDgHP5HGqP4KQjdmX9Yw@mail.gmail.com>
References: 
 <CABiQX1X2inguyAWWy5_zoc8Y_ztFawUKEsE-O23H+QAzHfxxuw@mail.gmail.com>
	<CADVgkyPhjemgUHR0KnAfdHowpuK1yHbRv1mL0ak-saMe0gkqug@mail.gmail.com>
	<CABiQX1XrzH0nzVE6gRYE9vNaxS0AP+pDgHP5HGqP4KQjdmX9Yw@mail.gmail.com>
Date: Fri, 25 Jul 2014 17:24:13 -0700
Message-ID: 
 <CAMSbhBg84JOaWF7sus=zPjDE5-_vKzXCJKoGCeTasPJW2DYp6A@mail.gmail.com>
Subject: Re: What's Stopping us From Independent Platform Releases
From: Steven Gill <stevengill97@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e0149cf949baa7f04ff0db5c7

--089e0149cf949baa7f04ff0db5c7
Content-Type: text/plain; charset=ISO-8859-1

We should give some notice about version change since some downstream dists
or tools might rely on cadver-semver.

I can write a blog post next week about it.

We also need to be very clear about which versions are pinned to cli.
Communicate that to our users in tools release blog posts and maybe some
config file?

What about removing platform specific stuff from cli? If we manage to dumb
down the cli now, it will hopefully remove potential compatability issues
later for platforms and cli. That might matter if we want to preserve older
clis supporting newer platforms.

Summarizing version changes at releases (if I understood this correctly)
- Platforms release independently.
- A tools release follows a platform release. Pinning the new platform. If
the platform was a major release, cli version takes a major bump
(ex Cordova-android goes to 4.0.0, cli goes to 6.0.0). If minor or patch
release for platform, cli version reflects that (ex android 4.1.1, cli
6.5.1)
- cli version will increase at a much faster pace than platforms. That's
fine and expected. This is because it has to take changes from all
platforms.


On Friday, July 25, 2014, Andrew Grieve <agrieve@chromium.org> wrote:

> On Fri, Jul 25, 2014 at 7:03 PM, Brian LeRoux <b@brian.io <javascript:;>>
> wrote:
>
> > > cordova-js:
> > >  - cordova.version returns a value computed from the cordova-js git
> tag.
> > >    - Let's deprecate this field
> > >    - And create "cordova.platformVersion"
> > >    - And update our release process to have the version set based on
> the
> > > platform's version rather than the tag within cordova-js.
> > >
> > >
> > This is a very good idea. +1
> >
> >
> >
> > > Cordova-docs:
> > >  - Most of the docs are not actually affected by platform versions.
> > >  - Mainly though, it's the platform guides that are.
> > >  - Two options that I see:
> > >    - 1) Set default version to "edge" & always annotate with "added in
> > > X.X.X, removed in X.X.X"
> > >    - 2) Move guides to live in platform repos and link to them from
> docs.
> > >
> > >
> > Think both are good ideas also. Going to edge for docs should be easy
> > enough. #2 means someone would have to look at the docs gen ...which I
> guess
> > isn't as terrible now that we have a Vagrantfile in there.
> >
> >
> >
> > > cordova-cli:
> > >   - Set version to 4.0.0 just to make it so that it doesn't map to any
> > > existing platform versions
> > >
> > >
> > you mean start a 4.x release branch ? (kinda hope we can ship this sooner
> > than later to help it bake.)
> >
> I just mean drop the CadVer-SemVer scheme.
>
>
> >
> >
> >
> > > Release Process:
> > >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> > >   - Rewrite
> > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > as "platforms-release-process"
> > >
> >
> > +1
> >
>

--089e0149cf949baa7f04ff0db5c7--