cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tommy-carlos williams <to...@devgeeks.org>
Subject Re: Releasing Platforms Independently
Date Thu, 13 Mar 2014 22:02:45 GMT
+1 for docs.

Pretty big pain point for devs.

On 14 March 2014 at 7:01:18 am, Brian LeRoux (b@brian.io) wrote:

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. 
> 


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