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
