cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [DISCUSS] Release 3.5.0
Date Mon, 05 May 2014 14:39:17 GMT
Option 2 makes sense to me.
- Maybe let's make a lib/ directory, and cordova-js and cordova-lib can go
there?
  - I don't think we need to put this on dist/ until we start to use it via
npm (I know it's there, but it's not used)
- I don't think we should "release docs". Don't want to have to vote every
time we make a tweak to them.

Also - thanks Steve for updating
https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md(everyone
- have a look!)
Some further thoughts on changes:
- Should we do away with adding "rc1" to RCs? Presumably the existence of
the release branch should serve the purpose os people being able to test
the right thing. Once it's tested & it's vote time, we can't have "rc" in
the version.
- Voting might go smoother if we vote on platforms separately. E.g. I
wouldn't be willing to vote platforms that I've never touched.



On Fri, May 2, 2014 at 6:01 PM, Steven Gill <stevengill97@gmail.com> wrote:

> Releasing options for 3.5.0.
>
> Option 1: Release like we always have.
> * One zip containing zips of the platforms, js, docs, cli
>
> Option 2: Break up platforms/tools/plugins
> This is the option we are going towards with independent releases.
> * Platforms go in the platforms directory
> * Tools in the tools directory
> * Plugins in the plugins directory
> * where does cordova-js go? Tools directory? Since this will also be
> released on npm, we need to release it on dist somewhere as well.
> * do we need/want to release docs still? If yes, we should create a top
> level docs directory
> * cordova.io downloads section will need to reflect the change
>
> You can see both option 1 & 2 at [1]
>
> I personally like option 2 since this is the direction we are going towards
> with independent releases. All the platforms will be released on npm once
> the 3.5.0 vote concludes. I don't see much value in having one zip that has
> zips of all of our platforms, cli, js + docs anymore.
>
> [1] http://www.apache.org/dist/cordova/
>
>
> On Thu, May 1, 2014 at 7:01 PM, Ian Clelland <iclelland@chromium.org>
> wrote:
>
> > At this point, I have to agree. I found a couple more issues while
> sorting
> > things out today that make me think it's not as obviously clean as it
> would
> > have to be to be in 3.5.0.
> >
> > (The hope was originally that the public interface would be *exactly* the
> > same, so it would be obvious that there were no compatibility issues, but
> > it's a bit more complicated than that now :( )
> >
> > For now, it can stay on a branch, and we can experiment with it until
> it's
> > ready for merging. No need to hold up the rest of the cadence train for
> one
> > feature.
> >
> > Ian
> >
> >
> > On Thu, May 1, 2014 at 12:06 PM, Steven Gill <stevengill97@gmail.com>
> > wrote:
> >
> > > I agree with Marcel. We should give it more time and bump it to a
> future
> > > release.
> > > On May 1, 2014 8:42 AM, "Marcel Kinard" <cmarcelk@gmail.com> wrote:
> > >
> > > > Given the recent thread on "customer pain points", I'd suggest that
> > this
> > > > capability be released when there is confidence that it works well,
> and
> > > any
> > > > breakages are understood and minimized. Reading the other threads,
> > sounds
> > > > like it's not quite there yet.
> > > >
> > > > On May 1, 2014, at 10:02 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > > >
> > > > > Should we just be cautious and bump to 3.6, or do we give you till
> > > > Monday?
> > > > >
> > > > >
> > > > > On Thu, May 1, 2014 at 9:54 AM, Ian Clelland <
> iclelland@chromium.org
> > >
> > > > wrote:
> > > > >
> > > > >> Currently, I think that pluggable webview is a non-starter for
> > 3.5.0;
> > > > >> there's an unfortunate backwards-incompatibility introduced by
> > > > abstracting
> > > > >> CordovaWebView from a class into an interface.
> > > > >>
> > > > >> /me swears at Java for not having either multiple inheritance
or
> > > > non-static
> > > > >> fields on interfaces...
> > > > >>
> > > > >> I'm playing with one possible solution to this today; if it works,
> > > then
> > > > we
> > > > >> might be able to get this in to 3.5, but I'm not 100% confident
> yet.
> > > > I'll
> > > > >> have to let you know later today.
> > > >
> > > >
> > >
> >
>

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