> I tested the branch for Asguard and Coyote. > By testing I mean running the robot and > navigate in the sand field. That is very impressive. However, it is not what I am discussing. I *know* that you want releases to be rock-solid (pun not intended), and I am very grateful that you took so much time testing it. But the question is about how the releases are going to work, not how well-tested they are. Ideally, previous Rock release should have been as well-tested (but were not).
In other words, the issue I have is the way the releases are implemented, not the fact that we have one. > The main issue that is solve by this, is that you don't get > updated, because stable/next/master moved on. Now you > need to change the release explicitly. What puzzles me is that you seem to think that the flavor system goes against having a proper release (at least, that's how I explain how much you changed the package sets and the name of the wiki page). The two thing needed to change a stable flavor into a release is: - adding a new flavor that inherits stable with the right name. Then you get the branching right (i.e. autoproj tracks the release name instead of 'stable') - adding the necessary overrides, which is something a little bit of scripting could do very easily (all the infrastructure is there because of "autoproj snapshot") What you do get is: - a way for people to tell "package X needs to go in the release" (they move it to the stable flavor) - very little changes between the dev and released system (package-set-wise), thus avoiding build issues, forgotten packages that got deleted, this kind of stuff. > Also I tried to freeze all external dependencies. The only > ones not being frozen are the ruby ones. Is there a way > to specify, which versions of the gems get installed ? Yes, but that's going to be a pain. Enabling it is part of the whole snapshotting work. > I don't see why you can't mix devel with release code. > You just set the override for the branch to whatever > you want, done. This fails if: - the master branch needs an osdeps that was not declared at release time - you want to try a package that did not exist at release time - the master branch depends on a package that did not exist at release time - the way the package got built changed between the release and now - the repository URL changed between the release and now - there are differences in the way the package is patched - probably other that I don't remember I've not implemented support for all these in the flavor system just for fun ... They were all concrete problems that people encountered (the most problematic one being gui/vizkit that changed from cmake_package to ruby_package). I also believe that synchronizing the release of rock-core and the rest makes no sense, but see http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases Sylvain _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
