Community
Participate
Working Groups
When running releasolor for the Kernel and the Web-Server it will loose the versions. This can be updated manually by updating all the versions in web for the lower repos.
Chris, this is an enhancement, right? Also, can you provide more description? Is this similar to the restartable ripple requirement?
I could argue either way but I'm not really bothered. Until this is done there is a manual step in the release process that opens it up to human error. Not something I want in the release process. As releasolor is split in two, versions do not get carried across and you have to update all the versions in the web repo by hand (using update dependencies) before starting releasolor for the web-server release.
By the way it is releaselor, not releasolor. I fully agree with the idea to get a manual step out of the release process. There is an assumption here that all the relevant versions appear in the web repo's build.versions file. (We could put them all in, I suppose.) A way to get the versions list accumulated from the previous step would be good. It sounds like the restartable ripple problem -- the principal implementation feature of which is the carry over of the versions accumulated -- and sounds like a similar solution.
I have already checked when doing RC1, all the relevant versions do occur in just the web repo.
With the introduction of virgo-root and the switch to Gradle (Bug 463462) this seems obsolete, now.