cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Releasing Platforms Independently
Date Tue, 18 Mar 2014 03:38:51 GMT
On Fri, Mar 14, 2014 at 1:02 PM, Shazron <shazron@gmail.com> 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 <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.
> >
> >
> > 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.
> >
>

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