cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Independent platform release summary
Date Tue, 07 Oct 2014 17:56:00 GMT
Parashuram -- I was thinking the Hangout would be the time to debate &
establish the pros/cons (and alternatives).  Trying to summarize before a
discussion/debate may not be accurate -- however, please feel free to
update the doc any way you think will benefit the conversation.

On Tue, Oct 7, 2014 at 1:27 PM, Steven Gill <stevengill97@gmail.com> wrote:

> Thanks for organzing a hangout Michal. We badly need it. Lots of great
> points have been made and I'm hoping we can all reach a consensus on this
> issue and move past it.
>
> On Tue, Oct 7, 2014 at 10:24 AM, Parashuram Narasimhan (MS OPEN TECH) <
> panarasi@microsoft.com> wrote:
>
>> Thanks Michael for the document, discussing it would be much easier.
>>
>> Do you think we should change the proposal sections to also list the
>> pros/cons of each approach? This way, we would also capture various
>> concerns raised in this thread.
>>
>> -----Original Message-----
>> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
>> Mocny
>> Sent: Tuesday, October 7, 2014 8:52 AM
>> To: Michal Mocny
>> Cc: Joe Bowser; dev
>> Subject: Re: Independent platform release summary
>>
>> Created a doc to summarize.  Trying to keep it concise and free of
>> opinions/conclusions, only context & goals.
>>
>>
>> https://docs.google.com/document/d/1VqAVo2AA5vZ7LRmq_9jJ6oa7Nyr2OrjLCfEkBhO-X8U/edit?usp=sharing
>>
>> On Tue, Oct 7, 2014 at 11:02 AM, Michal Mocny <mmocny@chromium.org>
>> wrote:
>>
>> > +dev list again :P
>> >
>> > The timezone in the doodle is EST but there is a switcher to set your
>> > own (surprised it didn't do that).
>> >
>> > On Tue, Oct 7, 2014 at 11:01 AM, Joe Bowser <bowserj@gmail.com> wrote:
>> >
>> >> What timezone is this meant for?
>> >>
>> >> On Tue, Oct 7, 2014 at 7:59 AM, Michal Mocny <mmocny@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 <jsoref@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.
>> >>>
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
>

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