On 01.03.2006, at 21:51, Simon Michael wrote:
Me too - thank you Marcus, Jerome, Bert and all others.
Marcus, would it be possible to have a breakdown of that log you just posted, suitable for folks who've been away from things ? I think:
- the 700x numbers are release numbers, corresponding to release
announcements, uploaded images etc. Two "unstable releases" were announced here.
In 3.9a we are trying to use Monticello for managing the image...
The update numbers (700x) are the number of changesets put in the update stream. The changeset loads one package ("ScriptLoader") that then has a build-script, mainly loading a set of Monticello packages from the squeaksource server, sometimes the scriptloader script has a postscript when needed (e.g. deleting preferences).
- ------ separates logical changes or change sets, though probably
not actual changesets just at the moment ? No, it looks like the second one was a changeset. One of these logical changes (updates ?) might include fixes for many mantis issues (the 000xxxx numbers).
the text was done by hand and follows no logic ;-) the numbers are manits bug numbers, yes. I don't post the full description there, but when a changeset was done with a nice preamble, I choose mostly to post that instead of the mantis number.
The best name for the release-numbers would be "build" I'd say: I load changesets (or fix stuff directly when seeing a simple to fix bug). Then I commit regularly to the source.squeakfoundation.org repository. When changes have piled up to be big enough for making it worth the effort, I make a build script, put in on the updatestream and upload an image.
As I said, the setup is far from perfect.... and we really need to improve it. e.g. updating is far too slow, and updating over multiple builds is broken...
I like MC as a versioning system (it should be speed up at bit...). But for providing what we had with the update stream it's not as good... what I would like would be a mix of the two: MC builds changesets that it then loads. There is a feature in SqueakSource that allows this to be done on the server an then cached (Bert implemented that). But this brakes down as soon as you change the code in the image via a normal changeset or a postscript: The diff the server builds between version is not the diff between the real images, as the postscript is ignored. But it should be possible to build a changeset when building the release image.... somehow, with taking the postscripts into account. This could then even set all MC data (e.g. version number) correctly, beeing a true diff.
This then should be available for people through the update stream, allowing for fast update without the need of having MC load ad decompress and diff everything on all clients... anyone would like to try implementing that?
And besides that, we need to automate much much more... I would like to have a system where I can commit to SqueakSource, and every night a build is done *completely* automatic, with image generation+upload, mail to list with changelog, generation of a changeset for the updatestream, everything.
- changes sometimes have no author information. That means they've
come from.. where ?
Either I have forgotten the author information (which would be bad, sorry to everyone who had that happen). Or the change is from me (e.g. I refactored some code now that CompiledMethods know their Selector and Class, or some small stuff, or stuff for the NewCompiler overrides/ ClosureRuntime merge).
Marcus