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.
