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 repository.yml. 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 yet). david zuhn Saint Paul, MN -- The State Belt Railway of California zoo @ statebeltrailway.org
