[GitHub] sterlinghughes opened a new issue #157: Make it easier to pin a version to a specific tag

[GitBox <gi...@apache.org>]

sterlinghughes opened a new issue #157: Make it easier to pin a version to a specific tag
URL: https://github.com/apache/mynewt-newt/issues/157
 
 
   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

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services