cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Releasing Platforms Independently
Date Tue, 18 Mar 2014 03:49:31 GMT
Awesome to hear enthusiasm here! :)

So... any volunteers to
a) Make a proposal to *how* to change the docs, and
b) Code up docs changes?


On Mon, Mar 17, 2014 at 11:38 PM, Michal Mocny <mmocny@chromium.org> wrote:

> 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