On Tue, Apr 28, 2015 at 4:19 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

I will soon release a ��versioner commit tool�� who will help with this.
The process will remain as now:

you do your changes
you do ��commit version of X�� (where X can be from ��Rubric�� to ��GTSpotter�� (and in the hopefully not far future even ��Nautilus�� or, why not ��Pharo-IDE�� or even ��Pharo��)
tools will collect packages and configurations and generate new ones, using semver nomenclature.
finally, you will copy your ��main�� configuration (the root of your change) to the inbox (same as now).

this is the beginning of the end of SLICEd based development.
and this is the beginning of a modular era :)

This is almost ready and is a good example of incremental changes that produces a fundamental lap (remember ��nomads do not build cathedrals�� talk from Marcus):

- gofer allows the scripting of commit and load packages
- metacello allows us to declare and manage dependences
- versionner does a very good job maintaining metacello configurations
- version commit tool will allow the automation release pacthes for nested configurations

Esteban

ps: and when I said almost ready, it is for real: I hope to release an alpha version for testing tomorrow :)
pps: sounds bad to put this last tool in the list to the big contributions�� at the end, is just a small tool on top of really important projects :))

��

Thanks Esteban. This sounds a good initiative to pull these parts together.�� I look forward to give it a try.

��

I still maintain there is a��need for a tool to merge��two Configuration's resultant-set-of-packages (similar to what is done a Slice's dependants) to facilitate parallel paths of development.��For context, when reviewing resolved issues, I use Monticello's merge tool to review the individual changes of a Slice before loading it.�� I also find that list a great reference after loading the Slice. My issue review workflow simultaneously starts two merges and completes one, leaving the other open as a reference. Then I can Browse direct to the affected methods and drop halts in them to get into the debugger to understand what is going on.��

��

There is also a broader issue here. Unless I'm missing something, when loading a Configuration we are blind to what the changes will be. This has some small security implications.

��

I envisage merging a Configuration's resultant-set-of-packages *somehow* plugs into the existing merge tool. �� A Slice's resultant-set-of-packages is directly specified by its dependants list, so where that list is passed for further merge processing of individual packages, at that point I thought we might be able to pass in a Configuration's resultant-set-of-packages -- but I haven't looked into this yet.

��

cheers -ben

��

> On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean@clipperadams.com> wrote:
>
> stepharo wrote
>>�� - we do a fix we publish it in Pharo and yes this touches Rubric and
>>�� - we�� integrate it in Pharo head
>
> I'm not clear what the best process is, but I wanted to relate an experience
> I just had updating TxText...
> Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor,
> which I wanted to copy to the TxText repo, is
> Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I�� checked
> the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking
> others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it
> over, and updated the config.
>
> So, for external projects, simply taking changes from the inbox and
> integrating seems to be a little lacking. Maybe at least copy the packages
> back to the canonical repos to preserve the ancestry...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-tp4821054p4822252.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>