Hi David, On Mon, Apr 09, 2018 at 09:29:34PM -0500, david zuhn wrote: > 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).
I agree - more flexibility here would be an improvement. I think you have a good understanding of the system. Here is my summary of how it currently works: * The `project.yml` file consists of "repo specifiers." * A repo specifier contains a single "version string." * A version string has one of the following forms: * Normalized: "#.#.#" * Floating: "#[.#]-<stability>" where <stability> is "dev", "latest", etc. Each Mynewt repo contains a `repository.yml` file in its master branch. The `repository.yml` file: * Maps floating version strings to normalized version strings. * Finally, maps normalized version strings to git commits (branch, tag, or hash). I think this system works well for users who want to use official Mynewt releases. However, it may not be the best for more adventurous users. To solve your problem, I think you'll need to modify your repo's `repository.yml` file such that "0.0.0" points to the specific commit hash that you want to pin yourself to. For example: repo.versions: "0.0.0": "815254f5166ef3954b214efdd37549814521c9d6" For the future, I suggest we make the following changes to newt: 1. Allow a repo specifier (in `project.yml`) to directly specify a git commit (branch, tag, or hash). 2. Allow a `repository.yml` file to map a floating version number directly to a git commit, rather than requiring an intermediate normalized version. Chris