Yes!
Good push
now I understand what you meant with Universe.
Now two important comments for me:
The problem One is that we are creating another vocabulary
- Why not sticking with MetacelloRepositoryForPharo10?
Like that we will not have to explain an Universe is a metacello
repository.....
Second point: what I would like is to have that all the dependent packages and
configurations are copied into the metacelloRepository.
I do not want to have dependency to any external servers. This way we will
self-contained distribution.
Do you handle that?
Else this is great.
Stef
On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
> Hi Miguel,
>
> Thanks! It's great to see progress on this front!
>
> Cheers,
> Adrian
>
> On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá Martínez wrote:
>
>> Hi all,
>>
>> I have created three new repositories on squeaksource:
>>
>> http://www.squeaksource.com/UniverseForPharo10
>> http://www.squeaksource.com/UniverseForPharo11
>> http://www.squeaksource.com/UniverseForPharo12
>>
>> They are the repositories for the current versions of Pharo. The idea is
>> that each new release add a new UniverseForXXX repository and populates
>> it with the current UniverseForXXX packages of the stable release.
>>
>> Right now they are mostly empty, but should be populated by the
>> community and the ConfigurationOfXXX maintainers.
>>
>> Most ConfigurationOfXXX packages in
>>
>> http://www.squeaksource.com/MetacelloRepository
>>
>> should be copied to UniverseForPharo10. Which versions? The last known
>> version that is working correctly on Pharo 1.0. This will be the
>> official universe for Pharo1.0. No ConfigurationOfXXX should be stored
>> on UniverseForPharo10 if it is not working correctly on Pharo10.
>>
>> Then two things can follow:
>>
>> - If the package already has ConfigurationOfXXX package versions that
>> work in Pharo 1.1, those versions should be copied to
>> UniverseForPharo11.
>>
>> - If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer
>> want to create the configuration for Pharo 1.1, he/she must copy the
>> last working configuration for the package from UniverseForPharo10 to
>> UniverseForPharo11. There he/she can start modifying the package until
>> it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid
>> marking a broken configuration as released)
>>
>> This will permit to populate the UniverseForPharo11 based on the last
>> working package versions from UniverseForPharo10. From that point they
>> will likely diverge because of maintenance releases to the packages in
>> any UniverseForXXX repository.
>>
>> The same will must be done to migrate from UniverseForPharo11 to
>> UniverseForPharo12. You get the idea.
>>
>> With time, MetacelloRepository should be deprecated in favor of this
>> UniverseForXXX repositories.
>>
>> Anyone is free to copy a working version from a previous Universe to a
>> new Universe. They have read/write permissions to all.
>>
>> This setup will avoid the problems we are having right now with the
>> in-image changes that are rendering the ConfigurationOfXXX unusable in
>> distinct releases of Pharo.
>>
>> What this means to the end user:
>>
>> - For released version of Pharo
>>
>> They will have to use gofer this way:
>>
>> Gofer new
>> squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11"
>> project: 'ConfigurationOfMagma';
>> load.
>> ConfigurationOfMagma project latestVersion load.
>>
>> - For next releases of Pharo
>>
>> Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader"
>> ConfigurationOfMagma project latestVersion load.
>>
>> All this depends on conventions to find the appropriate universe for
>> each pharo release, and also in the support from tools (like gofer in
>> this example or the GoferProjectLoader if it is part of the core image).
>> The universe functionality of the tools right now rely on the
>> SystemVersion current majorMinorVersion string for deciding which
>> repository to connect to. This could be improved surely but for now it
>> works.
>>
>> I'm loading a new version of Gofer to PharoInbox with this functionality
>> added so if you want to load directly from the universes with gofer do:
>>
>> Gofer upgrade.
>> Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
>>
>> But wait to this change to be treated by Stephane or Lukas before
>> attempt it.
>>
>> Right now there is only Magma in the three repositories, but it
>> shouldn't be hard for the maintainers of the other Configurations to
>> help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
>>
>> This will benefit us as a community because the universes for the
>> released pharo versions will be mostly untouched (only maintenance
>> releases) and people will have the freedom to modify the configuration
>> in the unstable (currently UniverseForPharo12) universe without
>> affecting the users of the stable versions.
>>
>> Also, this will avoid to have a lot of conditionals inside the
>> ConfigurationOfXXX classes, because a given class will target a specific
>> Pharo release (the version on the newest universes could even delete the
>> methods for the old universe, because will likely won't work in the new
>> universe, deleting unnecessary and legacy code from the configuration)
>>
>> Comments and improvements welcome
>>
>> --
>> Miguel Cobá
>> http://miguel.leugim.com.mx
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
