On 3/21/16 9:48 AM, Sean P. DeNigris wrote:
Dale Henrichs-3 wrote
First, congratulations! Thanks!!
Dale Henrichs-3 wrote
A baseline is associated with a "git version", so there is no need to "pin the version down in a specific version" Yes, but I'm not talking about a version of my main project, but a version of a dependent project. Right ... but you were also talking about "pinning the version of a dependent project in a version of your main project" .... each git commit is a new version of your main project, the equivalent of a new numbered version in a configuration, so to "pin the version of a dependent project", you simply change the version of the dependent project ... which I did in the example I provided ...
Dale Henrichs-3 wrote
in a "git project" you have the option of changing the specific version associated with a baseline on "every commit" .... Again, yes, but what I want to do (and what I understood as best practice in the past) is to defer the linking to a specific version until I release a stable version of my main project. Okay ... in a git environment, the master branch of your project is the stable version and you do development on a separate "topic branch" like `dev` or `issue_88`. That is, while I'm developing, I can be much looser with my tracking of loose dependencies, e.g. commonly it is enough to specify that I always want #stable. Of course, symbolic dependencies are not a good idea for release versions, so I will want to override the loose dependency with a specific numbered version. As I've said elsewhere I think that a symbolic version scheme based on versions (#release3, #release3.1, #release3.1.2, etc.) is superior to #stable for Monticello-based projects (those using ConfigurationOf) and it your dependent project used this scheme, there would be no need to "override the loose dependency with a specific numbered version".
If the dependent project doesn't use this scheme then you are stuck with using "specific numbered versions" ... That means that on branch `dev` you'll change the version of the project to #stable and do your work, when you are preparing to merge your work on `dev` into the master branch, you will choose a "specific numbered version", replace #stable with the the numbered version, test, merge to `master` branch. The next time you start work on a new topic branch, you can choose to use #stable, or simply select the latest numbered version explicitly and develop away ... before merging to master in this scheme, just double check if there is new version availble and if not, you're good to go ...
Unfortunately, while I'm no longer getting the mentioned error, my override seems to be ignored - `ConfigurationOfBabyPhexample project stableVersion record loadDirective.` reports that the #stable version of BabyMock (1.3) will be loaded instead of the version 1.2 that I specified in my configuration. Did you use the example I provided or did you continue to try to use the original spec? The spec you provided didn't make sense to me (I figured it was copy paste errors)...
I created an issue in my GitHub project where it might be easier to reference the code (https://github.com/seandenigris/Baby-Phexample/issues/1) or we can continue to discuss here. Yeah, it will be much easier to get into specific details on github ...
Dale