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:

        "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.


Reply via email to