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-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.