> On 21 Apr 2015, at 12:52, Thierry Goubier <[email protected]> wrote:
> 
> 
> 
> 2015-04-21 11:49 GMT+02:00 Esteban Lorenzano <[email protected] 
> <mailto:[email protected]>>:
> 
>> On 21 Apr 2015, at 11:42, Ben Coman <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> btw, how do you merge Configurations?  For example, if I fix something "X" 
>> in my image and continue to work in it a month while the Image 
>> Configurations move forward, how do avoid losing that fix when I update to 
>> the latest Configuration ?
> 
> you *do not* merge configurations. 
> if you fix  something in a “configured” project, you submit your change to 
> proper repository (not as a SLICE, as regular packages), which in time will 
> be included (or not, if “project owner” rejects it) in a new configutation 
> that will be included in Pharo. 
> 
> The problem is that the configuration of the project used to version that 
> project inside the Pharo image isn't versionned inside Pharo, but instead in 
> the project itself.
> 
> So, on a regular basis, you have a message which says: I tried to load the 
> project X inside Pharo (where X, as an older version, is inside Pharo 
> already) and it breaks here and there.
> 
> It will bite us when we'll try to make use of the Minimal image and rebuilt 
> stuff on top of it; all those external projects have a tendency to redefine 
> their configurations and semantic versions on a regular basis, and Pharo does 
> not record where and which; which will make reproducing out of a Minimal 
> image a real pain, with breakages appearing from one day to another.
>  
> 
> that’s how any complex project works… and that’s how we should work too. 
> SLICES are just a patch that exists because our system still not modular 
> enough.

configurations have versions. 
the problem is that I made a mistake and I allowed people to express their 
integrable versions as “#development”… while is easier for them, it proved to 
be a problem because it breaks update process. 
So, solution is simple: no “symbolic” version will be allowed to be integrated: 
just fixed number versions. 
Then update process will know which package versions to load. 


> 
> Well, current system isn't much better, IMHO.

believe me, it is. 
would be better if system would be modular so we do not need to change 
everything to change a bit… but we’ll arrive there. 

> 
> A simple solution, would be to version in PharoXX/main, the exact 
> configuration used to load the external project.

nope, solution is to explicit version to load :)

Esteban

> 
> It is not the case today.
> 
> Thierry
>  
> 
>> 
>> Actually I guess it would be useful if a Configuration could be merged with 
>> the same GUI that merges a Slice.
> 
> well… monkey and integrator app (integrators use it) does the proper loading. 
> But I insist: configurations are not merged: versions are loaded, instead. 
> 
> cheers. 
> Esteban
> 
>> 
>> cheers -ben
>> 
>> On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> > On 21 Apr 2015, at 08:06, stepharo <[email protected] 
>> > <mailto:[email protected]>> wrote:
>> >
>> > It means that we should also add the repositories of these projects so 
>> > that MC can merge no?
>> well, but you should not merge this projects :)
>> 
>> >
>> > Le 20/4/15 22:19, Esteban Lorenzano a écrit :
>> >> they are handled separately, through configurations.
>> >>
>> >> cheers,
>> >> Esteban
>> >>
>> >>> On 20 Apr 2015, at 21:02, Pavel Krivanek <[email protected] 
>> >>> <mailto:[email protected]>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> these packages do not have a version in the Pharo50 repository:
>> >>>
>> >>> Athens-Balloon
>> >>> Athens-Cairo
>> >>> Athens-CairoPools
>> >>> Athens-Core
>> >>> Athens-Examples
>> >>> Athens-Morphic
>> >>> Athens-Text
>> >>> ConfigurationOfAthens
>> >>> ConfigurationOfGlamourCore
>> >>> ConfigurationOfGTInspectorCore
>> >>> ConfigurationOfGToolkitCore
>> >>> ConfigurationOfGTPlaygroundCore
>> >>> ConfigurationOfGTSpotter
>> >>> ConfigurationOfOSWindow
>> >>> ConfigurationOfRubric
>> >>> ConfigurationOfShoreLineReporter
>> >>> ConfigurationOfTxText
>> >>> ConfigurationOfVersionner
>> >>> ConfigurationOfZincHTTPComponents
>> >>> Glamour-Announcements
>> >>> Glamour-Browsers
>> >>> Glamour-Core
>> >>> Glamour-Examples
>> >>> Glamour-Helpers
>> >>> Glamour-Morphic-Brick
>> >>> Glamour-Morphic-Brick-Tests
>> >>> Glamour-Morphic-Pager
>> >>> Glamour-Morphic-Renderer
>> >>> Glamour-Morphic-Theme
>> >>> Glamour-Morphic-Widgets
>> >>> Glamour-Presentations
>> >>> Glamour-Rubric-Presentations
>> >>> Glamour-Tests-Core
>> >>> Glamour-Tests-Morphic
>> >>> Glamour-Tests-Resources
>> >>> Glamour-Tests-Rubric
>> >>> GT-Inspector
>> >>> GT-InspectorExtensions-Core
>> >>> GT-Playground
>> >>> GT-Spotter
>> >>> GT-Spotter-EventRecorder
>> >>> GT-SpotterExtensions-Core
>> >>> GT-Tests-Inspector
>> >>> GT-Tests-Playground
>> >>> GT-Tests-Spotter
>> >>> OSWindow-SDL2
>> >>> OSWindow-VM
>> >>> Rubric
>> >>> ShoreLine-Report-Core
>> >>> ShoreLine-Report-Settings
>> >>> ShoreLine-Report-UI
>> >>> TxText-AthensTests
>> >>> TxText-Model
>> >>> TxText-Styler
>> >>> TxTextTests-Model
>> >>> Versionner-Core-Commands
>> >>> Versionner-Core-Model
>> >>> Versionner-Spec-Browser
>> >>> Versionner-Tests-Core-Model
>> >>> Zinc-HTTP
>> >>> Zinc-Character-Encoding-Core
>> >>> Zinc-Character-Encoding-Tests
>> >>> Zinc-Resource-Meta-Core
>> >>> Zinc-Resource-Meta-Tests
>> >>> Zinc-Tests
>> >>> Zinc-Zodiac
>> >>> Zodiac-Core
>> >>> Zodiac-Tests
>> >>>
>> >>> Cheers,
>> >>> -- Pavel
>> >>>
>> >>
>> >>
>> >
>> >
>> 
>> 
>> 
> 
> 

Reply via email to