Hi Sean -

Actually, I had already figured that at some point Metacello would need 
to provide more explicit version designators :-) But this doesn't 
address my concerns about the cross-product of package and system 
versions. Quite the opposite: My concern is more that when you have five 
potentially supported image versions there is a high probability that 
just for simplicity people will only support certain combinations.

To give a concrete example, just yesterday there was a discussion on the 
Seaside list about Seaside 2.8 on Pharo 1.1. Apparently, it's no longer 
supported, and that's a fine choice for the Seaside developers. But it's 
not quite as clear-cut if it's an equally fine choice for the Pharo (or 
Squeak) users of Seaside 2.8. And here's the issue: If you assume that 
the Seaside configuration comes from the Seaside folks (stored as 
ConfigurationOfSeaside in the external repository) then you're 
completely buying into that particular set of supported configurations.

If, however, we wanted to support Seaside 2.8 in Squeak 4.2, we could 
start with an older configuration, simply provide a few required patches 
for it (in a separate repository if required), and have that be part of 
Squeak 4.2 and later versions. No support from the Seaside folks is 
required, we can decide as community if and how we want to continue to 
support it.

That is the system / package version cross-product that I'm concerned 
about. And a version designator doesn't do much to address it. The point 
is that if there's a sufficient number of users in our community who say 
"this is important for us, we want it to work" they should be able to 
support that software as part of a community effort regardless of 
whether the original project developers 'officially' support it or not.

Cheers,
   - Andreas

On 5/16/2010 5:05 PM, Sean P. DeNigris wrote:
>
> I eagerly read all the discussions and offer my humble contribution (posting
> to Pharo too, because I think the benefit is cross-platform):
>
> I'm overjoyed that we are digging in and making packages easily loadable (or
> clear that they are not).  I don't know what I'll do with all the hours I
> currently spend fishing for working versions ;-)
>
> Overall the goals seem to be (put best in a post from Mariano Peck):
> * have a specific catalog of working and tested projects for each platform
> (Pharo 1.0, Pharo 1.1, Squeak 4.0, Squeak 4.1...)
> * Be able to have a hudson server running and testing such configurations.
> * Unified way to load a project.
> * (I added this one) have the least amount of effort for the developer
>
> The Pharo and Squeak versions both sound intriguing.  I suggest one addition
> that would magnify all of the above, and eliminate the accidental complexity
> that versioning is adding to the mix:
>
> ***Extend Metacello specs to account for platform version (e.g. Pharo 1.0
> vs. 1.1)***
>
> In effect, since we are distilling the platforms down to the pure good stuff
> - each version is a whole different platform; from a developer's
> perspective, it's the same process porting to different forks and porting to
> new versions of the same fork - either way, incompatible interfaces.
>
> A hypothetical developer perspective:
> 	- Porting from Squeak to Pharo: I'm a developer with a project that works
> on Squeak 4.0.  Now, I decide to port it to Pharo 1.0.  So I crank up a new
> image and... wait, how do I load it?  I don't have a ConfigOf.  So I either
> alter the Config #squeak to #squeakCommon, or load manually.  Now, it
> doesn't load because there are classes that don't exist in Pharo, so one by
> one, I move the platform-specific code into Platform.squeak and
> Platform.pharo.
> 	- Pharo 1.0 to Pharo 1.1: Now, Pharo 1.1 is released, with even fewer
> classes - tight core, yay!  So I go through the same process, but now I have
> *three platforms* - Pharo 1.0, 1.1, and Squeak 4.0.
>
> User perspective: simple - I want to have *one* place to go where I know
> that all the packages there will work in my image, and cut out all the junk.
> And, if I'm feeling adventurous, I'd like *one* place to see what else is
> out there, but very clear that it's not up to community standards - for
> inspiration, to port to my platform, or to steal code :)
>
> Once you have Metacello handling the versions
> * the developers go from fork*version configs to one config
> * the version problem is handled
> * all other features of the current plans are preserved
>
> This is what I envision at the intersection of what's been proposed and
> Metacello versioning:
> * Configs are either:
> 	- in one central location; it won't matter because we went from
> projects*forks*versions Configs to just 1*projects.
> 	- or, kept with the projects they reference e.g. pick squeaksource.com, and
> every project repository keeps its own ConfigurationOf (might diminish the
> community involvement if read-only repos)
> 	>Andreas
> (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473):
> 	>Good things about it are that
> 	>it's community maintained. Everyone can update everyone else's
> 	>contributions and although that's not generally done, it offers a
> 	>community approach to making sure things work.
> * Each platform (fork + version combo) (via hudson server?  I don't know
> much about them) tries to load each Config from the central repository.  If
> it meets the community standards (no conflicts, tests, etc.), either the
> Config is copied to that platform/fork's list of compatible Configs, or a
> reference is added.
> * If it doesn't load, another list could be kept with the result of the
> attempt to load, so anyone who wants to use or port it has a heads up on the
> status.
>
> So:
> * we don't need a separate Config for fork*version platforms.   Right now,
> it seems the implementation and behavior are collapsed - we don't care where
> the actual Configs are (at least in the Pharo plan), as long as we know
> which ones work.  Which resolves Andreas's concern with a single repository:
> 	>  Andreas
> (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473):
> 	>  Also, I don't think that a single repository is a feasible option in the
> long
> 	>  term - it seems to me that supporting the cross-product of image and
> 	>  package versions is going to be problematic before too long. And of
> 	>  course browsing repositories with several dozen of packages to find what
> 	>  you need isn't exactly fun either.
> and eliminated manual fiddling with the Config file:
> 	>  Pharo proposal @
> http://groups.google.com/group/metacello/browse_thread/thread/42c088d58acfb363
> 	>  [developers will copy configs that work in Pharo x.y to]
> PharoxyMetacelloRepository, then add class>>load for Pharo 1.0 version.
> * there is still one place to install for a user's platform
> * you really do get "a standard way to load the packages on such repository:
> just send the message load" because the spec already knows whether it will
> work on that platform
> * you still get a Pharo [and Squeak] release with the correct repository as
> default (already added in Monticello Browser) - this is your list you copied
> over
>
> Thanks.
> Sean