release processes (was Re: [squeak-dev] [ANN] Fuel 1.8.1)

tim Rowledge tim at rowledge.org
Wed Jan 9 18:44:02 UTC 2013


On 09-01-2013, at 9:46 AM, Chris Muller <asqueaker at gmail.com> wrote:

>> You're relying then on the good/competent intentions of every flawed human with commit rights. The ability to just fix a typo is the inability for anyone to know what code you're actually running. Is that Foo 1.1 with that ostensibly inconsequential fix that broke an edge case, or the other one?
> 
> Well, one would only fix an _obvious_ typo that could not possibly
> break any edge cases.

My experience suggests that there is no such thing, sadly. Part of the problem is (or at least, was, in the past) that the simple process of building an install package isn't simple enough to trust fully. I'm thinking of distant past here, the days of VisualWorks 1.0 and Windows 3.1 and InstallShield and ritual self-abuse to get it all to hang together.

The process at ParcPlace back then was relatively simple and sensible;
when you start making release candidates, you start packaging them and the testing has to include installing them from those packages
every release candidate is run through the test suite of choice
after testing you gather together and discuss found problems and decide if any are worth the work of 'cracking the release' to fix, re-package and re-test. 
eventually you get too tired to do any more and release it

I guess it was slightly complicated by the practise of condensing the sources for every release, so any cracking that required a change to the image that could add anything to the changelog then required re-doing the condense.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Lightbulb over his head is burned out.




More information about the Squeak-dev mailing list