Convention on platform (e.g. Pharo1.3 vs. Pharo1.4) package naming

[Sean DeNigris]

I have a configuration for a project that is getting updated for both
Pharo1.3 and Pharo1.4. Most commits are common, so I don't want a
totally forked -Platform package a la:
spec for: #'pharo1.3.x' do: [
spec package: 'MyProject-Platform' with: 'MyProject-Platform.pharo13-
SeanDeNigris.30' ].
spec for: #'pharo1.4.x' do: [
spec package: 'MyProject-Platform' with: 'MyProject-Platform.pharo14-
SeanDeNigris.30' ].

So I guess I'll have to have two platform packages: one pharo common,
and one with the 1.3/1.4 specific code, right? If so, what do I name
these?
MyProject-Platform & MyProject-PharoCommon?
In three Pharo versions, will I have MyProject-Platform & MyProject-
PharoCommonTo13and14 & MyProject-PharoCommonTo15and16 &....? And what
if Squeak was supported, too!?

Anyway, forget all my wild speculation. What's the bet way to handle
this and is there an example I can look at?

Thanks.
Sean

[Dale Henrichs]

Sean,

If you use the package branch naming scheme then you have the advantage of being able to define the dependencies for MyPlatform once in the #common section ... then you only need to the file name trick in your version (BTW if you want bleedingEdge loads to work correctly you should declare the branch in the baseline too):

MyProject-Core
MyProject-Platform.pharo13
MyProject-Platform.pharo14
MyProject-Platform.squeak
MyProject-Platform.gemstone

I've used this style for the Metacello-Platform. Technically you're not doing real branches in this scheme, but "what's in a name?"

Naming packages with the version in the name itself forces you to specify the dependencies for each version

MyProject-Core
MyProject-Platform-Pharo13
MyProject-Platform-Pharo14
MyProject-Platform-Squeak
MyProject-Platform-Gemstone

You can see how this style is used for ConfigurationOfGrease in the gemstone packages ...

If push came to shove, I'd lean towards the latter style (versions in name). You have to have unique packages for each of the target platform one way or the other.

BTW, you can fabricate a #pharocommon attribute if you find that you have code that is common for all of Pharo, but different for Squeak and GemStone ...

Dale

[Sean DeNigris]

On Dec 6, 11:25 pm, Dale Henrichs <dhenr...@vmware.com> wrote:
Naming packages with the version in the name itself forces you to
specify the dependencies for each version

>   MyProject-Platform-Pharo13

Thanks Dale. I'm going try this style since it's a personal project
and I always loadBleedingEdge anyway.

[Sean DeNigris]

It was actually pretty straightforward that way!

Here's the baseline I came up with...

baseline10: spec
<version: '1.0-baseline'>

spec for: #'common' do: [
spec blessing: #'baseline'.
spec repository: '/path/to/Setup/'.
spec
package: 'DeNigrisSetup-Core';
package: 'DeNigrisSetup-OB' with: [
spec requires: #('DeNigrisSetup-Core' ). ].
spec group: 'default' with: #('DeNigrisSetup-Core' ). ].

spec for: #'pharo1.3.x' do: [
spec

package: 'DeNigrisSetup-Core' with: [ spec includes:
#('DeNigrisSetup-Pharo13' ). ];
package: 'DeNigrisSetup-Pharo13' with: [ spec requires:
#('DeNigrisSetup-Core' ). ] ].

spec for: #'pharo1.4.x' do: [
spec

package: 'DeNigrisSetup-Core' with: [ spec includes:
#('DeNigrisSetup-Pharo14' ). ];
package: 'DeNigrisSetup-Pharo14' with: [ spec requires:
#('DeNigrisSetup-Core' ). ] ].

Some things I noticed:
* it's cool how 'common' is processed first, and then customized in
'pharo1...'
* For my personal utility projects (loaders, image customizers), this
MyProject-PlatformName approach is easier because I don't have to
define versions and can just load via #bleedingEdge.
* #fetch is key to see what the configuration would do in different
settings. I ended up printing "ConfigurationOfDeNigrisSetup project
bleedingEdge fetch loadDirective" in various images to double-check my
understanding.

Thanks for the help!