OK, let's try this again: What time zone is this mean for?
BTW: Can we get that fixed? On Tue, Oct 7, 2014 at 7:59 AM, Michal Mocny <mmo...@chromium.org> wrote: > Here is a doodle for those interested -- but if this timeline is too hasty > we can figure out a future date: http://doodle.com/a2nd8n3z8dm4ffbx. I'm > rather busy for two weeks starting next week (as are many of us in prep for > sh dev conf & pgday) so really hope we can do this this week. > > I'll put together a doc outlining some goals/non-goals and the current > proposals and we can discuss the tradeoffs and brainstorm options. > > -Michal > > On Tue, Oct 7, 2014 at 8:41 AM, Josh Soref <jso...@blackberry.com> wrote: > > > > > > > > > > (d) CLI versions completely independent of platforms, just like > plugins. > > > - In this case, we need to implement platform->cli version requirements > > > (node peerDependancies?) > > > - Basically means we play down CLI version entirely, users are just > > > expected to stay up to date with CLI always. Platform versions are all > > > that matters. I don't think this is too different than what we have > > today. > > > > I personally like (d) most. > > > > Say we start at 5.0.0 for cli. > > * When a platform updates, we can go to 5.0.1. > > > > * When cli adds a new feature, we can go to 5.1.0. > > > > * When the cli removes a feature/ platform , we can go to 6.0.0. > > > > Mostly, that should take us for 5.0.1000. Or occasionally to 5.2.5000, > and > > rarely to 6.0.5. > > > > Say a platform is at 3.7.0. > > * When a platform makes changes, it goes from 3.7.1. > > > > * When a platform adds a feature, it can go to 3.8.0. > > > > * When a platform drops support for a platform / configuration, it goes > to > > 4.0.0. >
