On Fri, Mar 14, 2014 at 1:02 PM, Shazron <[email protected]> wrote: > +1. especially for moving testing away from the mobile-spec monolith. > > Recently I discovered a bug > https://issues.apache.org/jira/browse/CB-6225that caused some pain for > users. Since it was all tested in mobile-spec and > it wasn't tested individually, it could not have been discovered (new Media > plugin has a new dependency on File -- when installed in mob-spec, all > plugins are installed). Having separate tests running in isolation would > have better discovered this. >
In full fairness, tests bundled with plugins would still rely on you to create an independent cordova project with each plugin to properly catch this case. The more common case is a single workspace with all plugins installed, since thats a lot easier. Should probably add a step to CI that tests in independent workspaces (do we have JIRA issues for CI? Theres no official set of CI tests for apache yet). > > > On Thu, Mar 13, 2014 at 8: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. > > > > > > 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) > > > > > > 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. > > > > > > > > Anything else? Please feel free to add inline here on things I've missed > > out, or on things you'd be concerned about changing. > > >
