+1 for docs. Pretty big pain point for devs.
On 14 March 2014 at 7:01:18 am, Brian LeRoux ([email protected]) 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 <[email protected]> wrote: > On Thu, Mar 13, 2014 at 11:38 AM, Andrew Grieve <[email protected] > >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. >
