On Tue, Apr 28, 2015 at 4:19 AM, Esteban Lorenzano <esteba...@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 <s...@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. > > > > >
