incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: Concerns about releasing 1.5
Date Mon, 27 Feb 2012 14:03:38 GMT
My own personal thoughts on the matter is when you have a public API like
we have with Cordova each release should be as good as the previous
release. That is, all existing features should continue to work. So things
where we are breaking all the plugins or changing the location of the root
file system don't sit well with me. I believe those are decisions that
should be discussed with the community and planned for a release instead of
just appearing in the next release.

Also, get off my lawn.

Simon Mac Donald
http://hi.im/simonmacdonald


On Fri, Feb 24, 2012 at 9:23 PM, Brian LeRoux <b@brian.io> wrote:

> > Are odd-numbered point releases advertised as unstable? Should they be?
>
> this is how nodejs and other unix-y projects do things
>
>
> > What is the downside to cutting a release with only congruent
> improvements
> > and bug-fixes?
>
> we've made no commitment on the plugin api (its never been official)
> so I don't feel we're breaking any promises
>
>
> > Personally I am also curious about why the changes are considered for
> > general(?) release in a staggered fashion.
>
> you can get a sense of the roadmap here
> http://wiki.apache.org/cordova/RoadmapProjects
>
> the general consensus is that this year we remove everything from
> phonegap api wise, plugin all the things, and then have officially
> supported plugins in addition to community ones. this work is a part
> of that effort. not pretty, but worthwhile in the long run.
>
> with conditional compilation of plugins anyone can compose a version
> of cordova suited to their project goals. plus, things should be
> lighter and more performant, in addition to having a better security
> story.
>
> (though w/ an avg hello world weighing in at 20kb and a bridge that
> gets 200 operations/second I've not seen a convincing argument
> otherwise)
>

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