I am quite sure that you already know all of this, but I just have urge to make some noice. :)
In Java world Maven handles this situation using term snapshot dependency. Non-snapshot release can/should not contain any snapshot dependencies. Contents of snapshot version is expected to change and non-snapshot releases are supposed to remain static. To me it looks like that these stable & co symbolic versions are quite the same than Mavens snapshot versions. Thus I think it would make sense have a functionality in metacello to "release" a version which would use the exact versions instead of symbolic ones. At least there there should be validation agains these issues. Possibly it should lock the monticello packages used to load the configurations also. IMHO it breaks the whole if so called stable version of project A depends on some other project which uses some symbolic version of some third project. When this third project advances it will eventually break the project A and thus the B in between does not seem so stable anymore. 2011/3/23 Dale Henrichs <[email protected]>: > Miguel, > > Two things: > > 1) there are certain conditions where #stable is the correct version to use > 2) I thought the point of running hudson-based tests is to identify these > types > of problems as soon as they occur so that they can be fixed earlier. > > With that said, I'd be inclined to create some scripts that recorded the > "configuration signature" of an image, something like the following: > > - Nile 1.2 (GuillermoPolito.19) > - OCompletion 1.2.2 (GuillermePolito.39) > - Pharo 1.1.1 (LaurentLaffonte.148) > - .... > > where the parenthesized info is the author and version of the mcz file. So if > an error shows up out of the blue, the first thing would be to check for > changes in the "configuration signature" and go from there ... > > We're already doing this kind of thing for the MetacelloBrowser, so it would > be very easy to whip up a script to build the signature ... I guess each > image could keep/generate it's signature.... > > I think the "configuration signature" is very useful ... if the > "configuration signature" doesn't change the exact same code should be loaded > ... > > Dale > > > On Mar 23, 2011, at 8:40 AM, Miguel Cobá wrote: > >> Maybe we should ask Dale when time permits to add functionality to >> Metacello so that can check all the dependencies for a given >> configuration and make sure (or raise some warning in the validation) >> that some dependency is refered by a symbolic non numeric version (like >> #stable, #latestVersion, #bleedingEdge) so that this validation can be >> run by hudson also and verify that all the configurations are frozen to >> a given number and no dependent on a symbolic version that can change >> anytime after release of Pharo when a package get a new (#stable for >> example) version. >> >> Cheers >> >> El mié, 23-03-2011 a las 13:26 +0100, Marcus Denker escribió: >>> On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: >>> >>>> Pharo 1.2 is red again! >>>> >>>> DuplicatedVariableError: stylingActive is already defined in Workspace >>>> >>>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ >>> >>> >>> We really need to make sure that the config does not load code if we don't >>> explicitly say so. >>> >>> So what code was changed? Why was it loaded? >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >> >> -- >> Miguel Cobá >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> > > > -- Panu
