lib directory sounds like a good idea for cordova-lib + cordova-js. I had the same thought about RC's last week. I chatted with Shaz about it and he seemed to agree as well. Instead of tagging with "rc1", we just tag the version it is (3.5.0). After the initial tag, people test. If errors are found and need to be fixed, we can just retag. This will save us time when it comes to releasing.
We will still release an RC for the CLI that points to the new platform tags. In terms of voting, one thread or many threads don't matter to me. CLI release would have to wait until all of the platform votes finish though. If one platform vote fails, the cli vote would fail. Rodrigo, thanks for stepping up to help! We aren't releasing plugins with this release, but we can do a plugins release shortly after. Let me know when you want to get that firefoxos pull request merged in. On Mon, May 5, 2014 at 7:39 AM, Andrew Grieve <agri...@chromium.org> wrote: > 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 <stevengil...@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 <iclell...@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 <stevengil...@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" <cmarc...@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 <mmo...@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 < > > iclell...@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. > > > > > > > > > > > > > > > > > > > >
