https://github.com/apache/incubator-mynewt-core/pull/197

[marko kiiskila <ma...@runtime.io>]

Hi,

I've tried this, and was wondering whether to merge it in it’s current form
or not.

This PR includes API changes for shell and console. While we have this:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy <https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy>
and there is a section about 'Backwards compatibility'.
How keen are we about enforcing it? Are people still getting used to the idea,
or should we be strict about it?

In general, this particular pull request contains stuff which will be useful for a people.
We want that. On the other hand, most of test target builds fail if I merge it in.
—
M

Re: https://github.com/apache/incubator-mynewt-core/pull/197

[Szymon Janc <sz...@codecoup.pl>]

Hi,

On Monday, 10 April 2017 20:50:15 CEST aditi hilbert wrote:
> Hi Marko,
> 
> Ideally, we should try to follow the release policy. And that means leaving
> the old API in, marking it “deprecated”, and pushing up the new API in
> parallel. The new app in the PR can work with the new functions and the old
> app can remain as is. The PR touches a lot of files so this may be a big
> undertaking.
> 
> The other option is to create a new feature branch to pull in the new
> changes. We mark the one on master deprecated but leave it in. The new
> feature branch has the new API and we put a comment on the functions that
> it is the recommended version. People who want to work with the new API can
> work on this branch.

I don't think that asking users to use dedicated branch for new functionality 
is a right way to go. We should focus on getting this into master in least 
conflicting way.

I think we should focus on getting RTT in first and then rest on top of that.
We will branstorm this tomorrow in the office. Hopefully we should be able to 
split this PR into smaller chunks as it grown a bit to big now...


> 
> thanks,
> aditi
> 
> > On Apr 10, 2017, at 9:55 AM, marko kiiskila <ma...@runtime.io> wrote:
> > 
> > Hi,
> > 
> > I've tried this, and was wondering whether to merge it in it’s current
> > form
> > or not.
> > 
> > This PR includes API changes for shell and console. While we have this:
> > https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Pol
> > icy
> > <https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+P
> > olicy> and there is a section about 'Backwards compatibility'.
> > How keen are we about enforcing it? Are people still getting used to the
> > idea, or should we be strict about it?
> > 
> > In general, this particular pull request contains stuff which will be
> > useful for a people. We want that. On the other hand, most of test target
> > builds fail if I merge it in. —
> > M


-- 
pozdrawiam
Szymon Janc

Re: https://github.com/apache/incubator-mynewt-core/pull/197

[aditi hilbert <ad...@runtime.io>]

Hi Marko,

Ideally, we should try to follow the release policy. And that means leaving the old API in, marking it “deprecated”, and pushing up the new API in parallel. 
The new app in the PR can work with the new functions and the old app can remain as is. The PR touches a lot of files so this may be a big undertaking. 

The other option is to create a new feature branch to pull in the new changes. We mark the one on master deprecated but leave it in. The new feature branch has the new API and we put a comment on the functions that it is the recommended version. People who want to work with the new API can work on this branch.

thanks,
aditi


> On Apr 10, 2017, at 9:55 AM, marko kiiskila <ma...@runtime.io> wrote:
> 
> Hi,
> 
> I've tried this, and was wondering whether to merge it in it’s current form
> or not.
> 
> This PR includes API changes for shell and console. While we have this:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy <https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy>
> and there is a section about 'Backwards compatibility'.
> How keen are we about enforcing it? Are people still getting used to the idea,
> or should we be strict about it?
> 
> In general, this particular pull request contains stuff which will be useful for a people.
> We want that. On the other hand, most of test target builds fail if I merge it in.
> —
> M