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 brian.leroux@gmail.com
 designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAEeF2Tf0=9t858Vj_bPoCde7xyJs54j_Q9XPcUYzUptx4=8zsQ@mail.gmail.com>
References: 
 <CABiQX1XudTfrF5HMyM9h9UYQ2jdZLm3SrYQKPjxUBU9tVw6aWQ@mail.gmail.com>
	<CAEeF2Tf0=9t858Vj_bPoCde7xyJs54j_Q9XPcUYzUptx4=8zsQ@mail.gmail.com>
Date: Thu, 13 Mar 2014 13:00:51 -0700
Message-ID: 
 <CADVgkyN7m2wdtoW2Jzy_8PKe-1XFpbmA_wwGR4vL48QSUF6=0g@mail.gmail.com>
Subject: Re: Releasing Platforms Independently
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec5299ad70a59d104f4826986

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

I definitely love the idea of making this part of the machine move faster,
and treating platforms as a dependency of the CLI in theory should not have
any cross cutting impacts *unless* we decide to change the plugin
interface. Our CLI version effectively becomes the 'Cordova' version. Docs
needs an overhaul regardless so I see no issue there.

How do you guys think we go about tackling this? Should we consider
starting w/ the Docs since that seems to be the squeakiest wheel?


On Thu, Mar 13, 2014 at 9:55 AM, Michal Mocny <mmocny@chromium.org> wrote:

> On Thu, Mar 13, 2014 at 11:38 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I think it would be beneficial if we could release updates to platforms
> > independent from others. Why?
> > - Far easier to do one-off platform releases (e.g. quick turn-around on a
> > security update, quick turn around on iOS is broken on the latest Xcode)
> > - Platforms can release on their own schedule (big new features will get
> > released sooner)
> >
> >
> > This doesn't come without bumps though. I'd like to use this thread to
> > explore the idea and to enumerate what would have to change to get there.
> >
> > Here are some things I can think of:
> >
> > Cordova-docs:
> > - We have a version drop-down in the top-right corner.
> > - I think this would mean getting rid of the version drop down (or
> rather,
> > not adding new entries to it).
> > - Always have people pointed at "edge"
> > - For things that refer to specific versions, put them inline
> >   - E.g. like we do for upgrade guides
> > - When a new API is introduced & is documented, we'll have to be better
> at
> > annotating what version it showed up in.
> >
>
> Huge +1.  This is a bit of an effort, sure, but every single damn time I
> search for a cordova question I end up on docs for cordova 2.3 or
> something, the version switcher takes me to home, and manually editing for
> "edge" doesn't always match urls.
>
>
> >
> >
> > Blog posts:
> > - We currently do one release announcement for all the platforms.
> > - I think it'll actually be a good thing to have shorter & more focused
> > release announcements (one post per platform)
> >
>
> I'm fine with this, but I do still think we want some special outlet to be
> "louder" about larger changes much like we have been with monthly cadence
> releases.
>
>
> >
> >
> > Mobile-spec:
> > - This is on the way out anyway I think, with moving tests into plugins.
> > - Even so, not a big deal to not have this strictly versioned.
>
>
> >
> > cordova-js:
> >  - Platforms will have cordova-js cut at different times.
> >    - I don't think this is a good or a bad thing.
> >  - JS versioning stamped at the top of the file:
> >    - Change to have both platform version as well as JS version available
> > at runtime.
> >    - JS version will just be a "git describe"
> >
> > CLI versioning:
> >   - It won't make sense to version it as CadVer-SemVer anymore
> >     - This essentially kills off the idea of CadVer.
> >   - That scheme wasn't working well anyways since you can't actually
> depend
> > on the SemVer part of it in a SemVer way (you can't say
> > dependency=">x.x.x-0.2")
> >   - CadVer-SemVer, I think, is causing people to not update their tools
> if
> > they aren't ready to update their platforms.
> >   - With this change, we should just have CLI be SemVer only.
> >   - If we move platforms to NPM, we wouldn't even need to push CLI
> updates
> > with platforms.
> >
>
> This is another huge benefit, I think.
>
>
> >
> >
> >
> > Anything else? Please feel free to add inline here on things I've missed
> > out, or on things you'd be concerned about changing.
> >
>
> Thanks for going over this.  Sounds to me like this is almost entirely
> upside.
>

--bcaec5299ad70a59d104f4826986--