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

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

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


----- Original Message -----
| From: "Sean DeNigris" <[hidden email]>
| To: "Metacello" <[hidden email]>
| Sent: Tuesday, December 6, 2011 6:35:14 PM
| Subject: [Metacello] Convention on platform (e.g. Pharo1.3 vs. Pharo1.4) package naming
|
| 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
|

On Dec 6, 11:25 pm, Dale Henrichs <[hidden email]> 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.

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!