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
