Re: [Pharo-users] BaselineOf's and Loose Dependencies
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! - Cheers, Sean -- View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749p4887415.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] BaselineOf's and Loose Dependencies
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
Re: [Pharo-users] BaselineOf's and Loose Dependencies
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. - Cheers, Sean -- View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749p4885766.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] BaselineOf's and Loose Dependencies
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: 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. - Cheers, Sean -- View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] BaselineOf's and Loose Dependencies
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: 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. - Cheers, Sean -- View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
