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 <[email protected]> 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
