Depending on MetaRepo instead of the target repo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Depending on MetaRepo instead of the target repo

Peter Uhnak
Hi,

would it make sense to take configurations from metarepos instead directly from the source?

And more imporantly: would be considered bad practice for users to do it right now?

E.g.

spec
        project: 'Magritte'
        with: [ spec
                className: #ConfigurationOfMagritte3;
                versionString: #stable;
                repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].

v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-)

cons:
* the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated

Any thoughts?

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Stephan Eggermont-3
On 12/02/17 13:03, Peter Uhnak wrote:
> would it make sense to take configurations from metarepos instead directly from the source?

Not really. They are not kept exactly up-to-date in practice, and having
one for each Pharo version is also kind of a bad practice.
What is missing is some pushing mechanism that makes sure that
configurations from the source repo get promoted to the metarepo when
they pass some ci (smoke) tests.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

stepharong
In reply to this post by Peter Uhnak

> Hi,
>
> would it make sense to take configurations from metarepos instead  
> directly from the source?

I do not think so but if people show me otherwise I could follow that.
Usually I have a conf in my repo referencing other repo and not the meta  
one
Then I push in the meta just to config.

>
> And more imporantly: would be considered bad practice for users to do it  
> right now?
>
> E.g.
>
> spec
> project: 'Magritte'
> with: [ spec
> className: #ConfigurationOfMagritte3;
> versionString: #stable;
> repository:  
> 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].
>
> v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'
>
>
> pros:
> * the (e.g. Magritte) developer can freely change platforms
> * the ConfigurationOf could differ between various MetaRepo versions  
> (combined with git it could reduce their complexity)
> * users do not have to think about where is the canonical repo (I've  
> seen project that had copies on SS, STHub, GitHub, and a custom location  
> -_-)
>
> cons:
> * the ConfigurationOf could differ between various MetaRepo versions (if  
> the code is compatible, then two repos have to be updated
>
> Any thoughts?
>
> Peter
>


--
Using Opera's mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Dale Henrichs-3
In reply to this post by Peter Uhnak
Peter,

<wishful thinking>

In the long term the the MetaRepo should be replaced by a repository of
project specification objects (like this [1]). Each project
specification would contain the meta data for a project (like this[2])
instead of a copy of a ConfigurationOf that is almost always out-of-date.

ConfigurationOf should really be phased out -- they've been obsolete for
3-4 years now... BaselineOf is preferred.

If folks are using something like git/github, with proper branching,
then a BaselineOf wouldn't be published on the master branch until the
unit tests are passing (travis-ci).

</wishful thinking>

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
On 2/12/17 4:03 AM, Peter Uhnak wrote:

> Hi,
>
> would it make sense to take configurations from metarepos instead directly from the source?
>
> And more imporantly: would be considered bad practice for users to do it right now?
>
> E.g.
>
> spec
> project: 'Magritte'
> with: [ spec
> className: #ConfigurationOfMagritte3;
> versionString: #stable;
> repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].
>
> v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'
>
>
> pros:
> * the (e.g. Magritte) developer can freely change platforms
> * the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity)
> * users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-)
>
> cons:
> * the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated
>
> Any thoughts?
>
> Peter
>


Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Ben Coman


On Sun, Feb 12, 2017 at 11:36 PM, Dale Henrichs <[hidden email]> wrote:
Peter,

<wishful thinking>

In the long term the the MetaRepo should be replaced by a repository of project specification objects (like this [1]). Each project specification would contain the meta data for a project (like this[2]) instead of a copy of a ConfigurationOf that is almost always out-of-date.

ConfigurationOf should really be phased out -- they've been obsolete for 3-4 years now... BaselineOf is preferred.

Does BaselineOf work with Monticello?
I thought it was only for use with git.

cheers -ben 
 

If folks are using something like git/github, with proper branching, then a BaselineOf wouldn't be published on the master branch until the unit tests are passing (travis-ci).

</wishful thinking>

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston

On 2/12/17 4:03 AM, Peter Uhnak wrote:
Hi,

would it make sense to take configurations from metarepos instead directly from the source?

And more imporantly: would be considered bad practice for users to do it right now?

E.g.

spec
        project: 'Magritte'
        with: [ spec
                className: #ConfigurationOfMagritte3;
                versionString: #stable;
                repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].

v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-)

cons:
* the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated

Any thoughts?

Peter




Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

stepharong
In reply to this post by Dale Henrichs-3
On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs  
<[hidden email]> wrote:

> Peter,
>
> <wishful thinking>
>
> In the long term the the MetaRepo should be replaced by a repository of  
> project specification objects (like this [1]). Each project  
> specification would contain the meta data for a project (like this[2])  
> instead of a copy of a ConfigurationOf that is almost always out-of-date.

Yes we are working on it.
Now 64bits, FFI, Iceberg, bootstrap got our attention.
>
> ConfigurationOf should really be phased out -- they've been obsolete for  
> 3-4 years now... BaselineOf is preferred.
>
> If folks are using something like git/github, with proper branching,  
> then a BaselineOf wouldn't be published on the master branch until the  
> unit tests are passing (travis-ci).

I want more than just the tests but this is a start.
>
> </wishful thinking>

We will arrive there. Because I want it too.
Now pavel worked on the bootstrap to avoid to lose all the energy that  
guille put on it.

>
> Dale
>
> [1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
> [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
> On 2/12/17 4:03 AM, Peter Uhnak wrote:
>> Hi,
>>
>> would it make sense to take configurations from metarepos instead  
>> directly from the source?
>>
>> And more imporantly: would be considered bad practice for users to do  
>> it right now?
>>
>> E.g.
>>
>> spec
>> project: 'Magritte'
>> with: [ spec
>> className: #ConfigurationOfMagritte3;
>> versionString: #stable;
>> repository:  
>> 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].
>>
>> v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'
>>
>>
>> pros:
>> * the (e.g. Magritte) developer can freely change platforms
>> * the ConfigurationOf could differ between various MetaRepo versions  
>> (combined with git it could reduce their complexity)
>> * users do not have to think about where is the canonical repo (I've  
>> seen project that had copies on SS, STHub, GitHub, and a custom  
>> location -_-)
>>
>> cons:
>> * the ConfigurationOf could differ between various MetaRepo versions  
>> (if the code is compatible, then two repos have to be updated
>>
>> Any thoughts?
>>
>> Peter
>>
>
>


--
Using Opera's mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Dale Henrichs-3
Very good to hear ... I have to try to be a bit more patient :)


On 2/12/17 9:37 AM, stepharong wrote:

> On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs
> <[hidden email]> wrote:
>
>> Peter,
>>
>> <wishful thinking>
>>
>> In the long term the the MetaRepo should be replaced by a repository
>> of project specification objects (like this [1]). Each project
>> specification would contain the meta data for a project (like
>> this[2]) instead of a copy of a ConfigurationOf that is almost always
>> out-of-date.
>
> Yes we are working on it.
> Now 64bits, FFI, Iceberg, bootstrap got our attention.
>>
>> ConfigurationOf should really be phased out -- they've been obsolete
>> for 3-4 years now... BaselineOf is preferred.
>>
>> If folks are using something like git/github, with proper branching,
>> then a BaselineOf wouldn't be published on the master branch until
>> the unit tests are passing (travis-ci).
>
> I want more than just the tests but this is a start.
>>
>> </wishful thinking>
>
> We will arrive there. Because I want it too.
> Now pavel worked on the bootstrap to avoid to lose all the energy that
> guille put on it.
>
>>
>> Dale
>>
>> [1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
>> [2]
>> https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
>> On 2/12/17 4:03 AM, Peter Uhnak wrote:
>>> Hi,
>>>
>>> would it make sense to take configurations from metarepos instead
>>> directly from the source?
>>>
>>> And more imporantly: would be considered bad practice for users to
>>> do it right now?
>>>
>>> E.g.
>>>
>>> spec
>>>     project: 'Magritte'
>>>     with: [ spec
>>>         className: #ConfigurationOfMagritte3;
>>>         versionString: #stable;
>>>         repository:
>>> 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].
>>>
>>> v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'
>>>
>>>
>>> pros:
>>> * the (e.g. Magritte) developer can freely change platforms
>>> * the ConfigurationOf could differ between various MetaRepo versions
>>> (combined with git it could reduce their complexity)
>>> * users do not have to think about where is the canonical repo (I've
>>> seen project that had copies on SS, STHub, GitHub, and a custom
>>> location -_-)
>>>
>>> cons:
>>> * the ConfigurationOf could differ between various MetaRepo versions
>>> (if the code is compatible, then two repos have to be updated
>>>
>>> Any thoughts?
>>>
>>> Peter
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Peter Uhnak
I do not think so but if people show me otherwise I could follow that.

Well, in most languages (their package dependencies) one can just specify name of the project and a version. The location/how to load it is pulled from a central repository.
So that's why I thought that maybe the MetaRepo could be used in a similar fashion.

> In the long term the the MetaRepo should be replaced by a repository of project specification objects

That also seems needlessly complex; basically just ConfigurationOf separated to parts. I do not want to restrict the users, but with a central repo the most common use case shouldn't be 10 lines of configuration.


Does BaselineOf work with Monticello?
> I thought it was only for use with git.

Monticello or Metacello?

You can download/install projects just fine (and also depend on other baselines from your baselines or configurations)

Metacello new
    baseline: 'FileDialog';
    repository: 'github://peteruhnak/file-dialog/repository';
    load.

Also BaselineOf is just a subclass of ConfigurationOf.



On Mon, Feb 13, 2017 at 2:48 AM, Dale Henrichs <[hidden email]> wrote:
Very good to hear ... I have to try to be a bit more patient :)



On 2/12/17 9:37 AM, stepharong wrote:
On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs <[hidden email]> wrote:

Peter,

<wishful thinking>

In the long term the the MetaRepo should be replaced by a repository of project specification objects (like this [1]). Each project specification would contain the meta data for a project (like this[2]) instead of a copy of a ConfigurationOf that is almost always out-of-date.

Yes we are working on it.
Now 64bits, FFI, Iceberg, bootstrap got our attention.

ConfigurationOf should really be phased out -- they've been obsolete for 3-4 years now... BaselineOf is preferred.

If folks are using something like git/github, with proper branching, then a BaselineOf wouldn't be published on the master branch until the unit tests are passing (travis-ci).

I want more than just the tests but this is a start.

</wishful thinking>

We will arrive there. Because I want it too.
Now pavel worked on the bootstrap to avoid to lose all the energy that guille put on it.


Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
On 2/12/17 4:03 AM, Peter Uhnak wrote:
Hi,

would it make sense to take configurations from metarepos instead directly from the source?

And more imporantly: would be considered bad practice for users to do it right now?

E.g.

spec
    project: 'Magritte'
    with: [ spec
        className: #ConfigurationOfMagritte3;
        versionString: #stable;
        repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].

v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-)

cons:
* the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated

Any thoughts?

Peter








Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Ben Coman


On Mon, Feb 13, 2017 at 7:28 PM, Peter Uhnák <[hidden email]> wrote:
I do not think so but if people show me otherwise I could follow that.

Well, in most languages (their package dependencies) one can just specify name of the project and a version. The location/how to load it is pulled from a central repository.
So that's why I thought that maybe the MetaRepo could be used in a similar fashion.

> In the long term the the MetaRepo should be replaced by a repository of project specification objects

That also seems needlessly complex; basically just ConfigurationOf separated to parts. I do not want to restrict the users, but with a central repo the most common use case shouldn't be 10 lines of configuration.


Does BaselineOf work with Monticello?
> I thought it was only for use with git.

Monticello or Metacello?

I meant, can a Baseline be stored in / operate from a mcz file, without a Configuration?
I thought git made Baselines feasible since git takes care of versioning.
 
cheers -ben


You can download/install projects just fine (and also depend on other baselines from your baselines or configurations)

Metacello new
    baseline: 'FileDialog';
    repository: 'github://peteruhnak/file-dialog/repository';
    load.

Also BaselineOf is just a subclass of ConfigurationOf.



On Mon, Feb 13, 2017 at 2:48 AM, Dale Henrichs <[hidden email]> wrote:
Very good to hear ... I have to try to be a bit more patient :)



On 2/12/17 9:37 AM, stepharong wrote:
On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs <[hidden email]> wrote:

Peter,

<wishful thinking>

In the long term the the MetaRepo should be replaced by a repository of project specification objects (like this [1]). Each project specification would contain the meta data for a project (like this[2]) instead of a copy of a ConfigurationOf that is almost always out-of-date.

Yes we are working on it.
Now 64bits, FFI, Iceberg, bootstrap got our attention.

ConfigurationOf should really be phased out -- they've been obsolete for 3-4 years now... BaselineOf is preferred.

If folks are using something like git/github, with proper branching, then a BaselineOf wouldn't be published on the master branch until the unit tests are passing (travis-ci).

I want more than just the tests but this is a start.

</wishful thinking>

We will arrive there. Because I want it too.
Now pavel worked on the bootstrap to avoid to lose all the energy that guille put on it.


Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
On 2/12/17 4:03 AM, Peter Uhnak wrote:
Hi,

would it make sense to take configurations from metarepos instead directly from the source?

And more imporantly: would be considered bad practice for users to do it right now?

E.g.

spec
    project: 'Magritte'
    with: [ spec
        className: #ConfigurationOfMagritte3;
        versionString: #stable;
        repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].

v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-)

cons:
* the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated

Any thoughts?

Peter









Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Peter Uhnak

> I meant, can a Baseline be stored in / operate from a mcz file, without a
> Configuration?
> I thought git made Baselines feasible since git takes care of versioning.

Git takes care of the versioning, so the Baseline is really just a baseline, like it would be in a ConfigurationOf.


Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Dale Henrichs-3
In reply to this post by Ben Coman



On 02/12/2017 08:40 AM, Ben Coman wrote:


On Sun, Feb 12, 2017 at 11:36 PM, Dale Henrichs <[hidden email]> wrote:
Peter,

<wishful thinking>

In the long term the the MetaRepo should be replaced by a repository of project specification objects (like this [1]). Each project specification would contain the meta data for a project (like this[2]) instead of a copy of a ConfigurationOf that is almost always out-of-date.

ConfigurationOf should really be phased out -- they've been obsolete for 3-4 years now... BaselineOf is preferred.

Does BaselineOf work with Monticello?
Technically, yes (bleeding edge), but practically no. That doesn't change the fact that ConfigurationOf should be phased out ...

There are so many things wrong with the way that ConfigurationOf works: manual editing required on every package commit, editable version data that should be immutable, no good branching model, no project-level version comparison, etc.

5 years ago,I was seriously looking at solving the problems with ConfigurationOf. I happened to be looking at git for inspiration (mainly the branching model), but was not really looking forward to the amount of work that was going to be involved.

Fortunately right about that time Otto Behrens introduced FileTree. Being able to leverage a fully featured version control system to manage Smalltalk code in FileTree, meant that instead trying to put effort into fixing ConfigurationOf, I was able to greatly simplify ConfigurationOf with BaselineOf ...

Project specification objects would support both ConfigurationOf and BaselineOf projects ... the current model of only supporting ConfigurationOf projects with a MetaRepo means that BaselineOf projects are not really properly supported....

Dale
Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

Dale Henrichs-3
In reply to this post by Peter Uhnak



On 02/13/2017 03:28 AM, Peter Uhnák wrote:
I do not think so but if people show me otherwise I could follow that.

Well, in most languages (their package dependencies) one can just specify name of the project and a version. The location/how to load it is pulled from a central repository.
So that's why I thought that maybe the MetaRepo could be used in a similar fashion.


You are correct that the MetaRepo could accomplish this using a ConfigurationOf (the current scheme basically does follow this model), but this is a bit of a hack ..

A better solution is to use a "project specification object" --- many other languages use their own flavor of "project specification object" to define the versions.

Having project specification objects means that a whole host of project meta data can be included in the object as first class objects without having to hack around with adding methods (by convention) to a ConfigurationOf


> In the long term the the MetaRepo should be replaced by a repository of project specification objects

That also seems needlessly complex; basically just ConfigurationOf separated to parts. I do not want to restrict the users, but with a central repo the most common use case shouldn't be 10 lines of configuration.
I don't agree that this would be needlessly complex ... the implementation I use with tODE leverages gh-pages on github and STON ... having first class objects for project specifications, means that tools can be built to work directly with these objects, instead of loading a ConfigurationOf and hoping that the expected meta data is there ...

Dale
Reply | Threaded
Open this post in threaded view
|

Re: Depending on MetaRepo instead of the target repo

stepharong
In reply to this post by Peter Uhnak
On Mon, 13 Feb 2017 12:28:11 +0100, Peter Uhnák <[hidden email]> wrote:

I do not think so but if people show me otherwise I could follow that.

Well, in most languages (their package dependencies) one can just specify name of the project and a version. The location/how to load it is pulled from a central repository.
So that's why I thought that maybe the MetaRepo could be used in a similar fashion.

we could too. :)


> In the long term the the MetaRepo should be replaced by a repository of project specification objects

That also seems needlessly complex; basically just ConfigurationOf separated to parts. I do not want to restrict the users, but with a central repo the most common use case shouldn't be 10 lines of configuration.


Does BaselineOf work with Monticello?
> I thought it was only for use with git.

Monticello or Metacello?

You can download/install projects just fine (and also depend on other baselines from your baselines or configurations)

Metacello new
    baseline: 'FileDialog';
    repository: 'github://peteruhnak/file-dialog/repository';
    load.

Also BaselineOf is just a subclass of ConfigurationOf.



On Mon, Feb 13, 2017 at 2:48 AM, Dale Henrichs <[hidden email]> wrote:
Very good to hear ... I have to try to be a bit more patient :)



On 2/12/17 9:37 AM, stepharong wrote:
On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs <[hidden email]> wrote:

Peter,

<wishful thinking>

In the long term the the MetaRepo should be replaced by a repository of project specification objects (like this [1]). Each project specification would contain the meta data for a project (like this[2]) instead of a copy of a ConfigurationOf that is almost always out-of-date.

Yes we are working on it.
Now 64bits, FFI, Iceberg, bootstrap got our attention.

ConfigurationOf should really be phased out -- they've been obsolete for 3-4 years now... BaselineOf is preferred.

If folks are using something like git/github, with proper branching, then a BaselineOf wouldn't be published on the master branch until the unit tests are passing (travis-ci).

I want more than just the tests but this is a start.

</wishful thinking>

We will arrive there. Because I want it too.
Now pavel worked on the bootstrap to avoid to lose all the energy that guille put on it.


Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
On 2/12/17 4:03 AM, Peter Uhnak wrote:
Hi,

would it make sense to take configurations from metarepos instead directly from the source?

And more imporantly: would be considered bad practice for users to do it right now?

E.g.

spec
    project: 'Magritte'
    with: [ spec
        className: #ConfigurationOfMagritte3;
        versionString: #stable;
        repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].

v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-)

cons:
* the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated

Any thoughts?

Peter











--
Using Opera's mail client: http://www.opera.com/mail/