I'm trying to understand how the newt tool manages repository versions.

Here's my situation -- I don't want to depend on github/master, yet I don't
want to introduce gratuitous incompatibility.

So I would like to redefine the apache-mynewt-core repository to be my own
repository (either my own fork on github, or perhaps an internal github
server). That's an easy change to make in project.yml.  No problem yet.

On my own fork, I like to keep master to be exactly the same as the
upstream master, although it may lag behind as I don't need to run a pull
constantly.   So I'm keeping my own changes in a development branch.

I'd like to specify this in project.yml, but the 'vers' field has some
strict guidelines about what I can use, and it seems that I can only use
master branch, so "0-dev" is "0.0.0" is "master" according to

I want to have everything I'm building in source control, for my Continuous
Integration engine if nothing else.   At the moment, I have a patch to the
BAS service in mynewt-nimble that I wish to commit.  I believe that it will
be in the official repository "soon" (for some definition of soon), but
that doesn't help the fact that I would like to check in (to my local
repositories my application that depends on this fix, which then entails
that I want to check in the fix too).

>From what I'm reading so far, it would be nice if the newt tool were a
little less picky about the format of the 'vers' tag, or had an alternate
tag that would let me bypass 'vers' altogether and let be specify a branch
name directly (which would also alleviate the need to special case "0.0.0"
to being "master").

Or is there a capability to do what I'm looking for that I just can't find
(I don't speak fluent go, so perusing the source hasn't shown me anything

david zuhn
Saint Paul, MN

The State Belt Railway of California
zoo @ statebeltrailway.org

Reply via email to