BaselineOf's and Loose Dependencies

I know this is not technically a Pharo question, but I'm in China on my honeymoon and can't access the Metacello Google group!

There was a pattern in pre-BaselineOf Metacello where one would define
dependencies loosely in the #baselineXyz:, and then pin them to a specific
version in the #versionAbc:.

For example:
   baseline100: spec
        ...
        project: 'BabyMock' with: [
                spec
                        className: #ConfigurationOfBabyMock;
                        versionString: #'stable';
                        repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ]
        ...
and then:
   version10: spec
        ...
        spec
                project: 'BabyMock' with: '1.2'
        ...

How does one handle this sort of thing with #baseline:import:?

This is what I came up with:
   version10: spec
        ...
        baseline: 'BabyPhexample'
                with: [
                      spec
                        repository:
                           
'github://seandenigris/Baby-Phexample:INSERT-SHA-HERE/repository' ];
                import: 'BabyPhexample'.
                spec
                        project: 'BabyMock' with: '1.2'
        ...
But I got this error from the last line: MessageNotUnderstood: receiver of "fetchUsing:" is nil

Thanks.

First, congratulations!

A baseline is associated with a "git version", so there is no need to
"pin the version down in a specific version" ... in a "git project" you
have the option of changing the specific version associated with a
baseline on "every commit" ....

So you would specify the BabyMock project as you would in the baseline*:
method from your ConfigurationOf and "override" the versionString in place:

  spec
     configuration: 'BabyMock'
     with: [
       spec
         versionString: '1.2';
         repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ]

Note, that I'm using the more modern form of project specification....
the above is equivalent to:

   spec
     project: 'BabyMock'
     with: [
       spec
         className: #'ConfigurationOfBabyMock';
         versionString: '1.2';
         repository ]

Dale

On 3/21/16 8:15 AM, Sean P. DeNigris wrote:

Sean (and others) I don't always keep up-to-date with the posts on the
pharo list, so if you have a Metacello-related question, put Metacello
in the subject line and I'll have a better chance of seeing the message ...

Dale

On 3/21/16 8:15 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.

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

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.

On 3/21/16 9:48 AM, Sean P. DeNigris wrote: 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
>

I had to think about this for a while. Let me see if I can summarize where we are:
- I wanted to translate the pre-BaselineOf workflow of "specify loose dependencies generally (e.g. #stable) in the #baselineXyz: method, and precisely in the #versionAbc: method" to "specify loose dependencies generally in the BaselineOf, and precisely in the ConfigurationOf"
- You're saying that I can't (or shouldn't?) do that, but should instead specify them generally in the dev branch, and pin them down each time I release, so I would:
  1. Commit dev with the specific versions
  2. Merge into master
  3. Commit dev again with the general project versions to continue my work

Does that all sound accurate?

Two things to note that I'm not sure were clear:
- I have no control over the other projects and assume they do not use the #releaseXyz discipline
- I do not generally use issue branches for projects that I work on alone because IMHO it adds much complexity to the workflow

Thanks!