2011/3/23 Dale Henrichs <[email protected]>: > Panu, > > I agree almost completely most of the project dependencies in configuration > _should_ use a literal version ... I still maintain that there are use cases > where using symbolic version like #stable is correct.
Your example was good. However in the long run when those #stable dependencies develop, old versions that depend on them became broken because of changed API/protocol and not because of a introduced bug. But using spesific versions would not solve this problem either just introduces new ones. Using version ranges could help a little but one could not know the range before hand. Of course if suggestion of semver would be used one could guess that next major release will probable broke things. > I have proposed the "configuration signature" because I have noticed that > some developers will change existing/released configurations (which could > cause problems) and I think that Pharo-1.2 just might be using several > versions with a #development blessing (where it is an accepted practice to > change the specification for a version) so any change in version of a > configuration mcz file is suspect ... I hope when things mature people start to obey these "rules". This same problems exist with maven also but people maybe know the consequences and don't go against the odds. On mission critical cases one is supposed to store all the required dependencies to avoid third party to fiddle with builds. Which is the case with Metacello too. > The problem with locking down the versions of everything is very similar to > the problem of static definitions of classes (in java) ... one change to a > class definition and there is a cascade of changes that must be made to the > rest of the system before you can get the whole thing to compile again.... > There _is_ tension between the desire to be able to guarantee reproducable > results and providing enough wiggle room to avoid putting development into > version grid lock ... I think these approaches should coexists. Some projects are very strict about repeatable builds. In some projects this will just create uneccessary overhead. > But I think the hudson server is actually doing it's job by loading the > configurations that a developer would be loading and finding problems that a > developer would otherwise find on his or her own ... the fact that the build > failed is a good thing and fixing the problem whether it be in a literal > version or a symbolic version is the important thing... Yep. IMHO sensible intergration builds are easier to do with Metacello than Maven + some scm. -- Panu
