On 19 July 2012 23:00, Chris Muller <asqueaker at gmail.com> wrote:
>> ... I had a brief look at the Squeak wiki to see if I could
>> find any checklist a release manager could use to orchestrate a new
>> Squeak release. (This is fairly timeous, I reckon, given that 4.3's
>> already over 6 months old.)
>>
>> I couldn't find anything. Where would one find such a list? (*) If ...
>
> I made a page when I did the 4.2 release and encouraged everyone to participate.
>
>     http://wiki.squeak.org/squeak/6160

OK, so part of the general release process is finding out what's
actually going to go into the release. I agree, that's important. I
was mainly looking for documentation such that some victim^Wvolunteer
could have a checklist that tells him/her exactly how to prepare and
deploy a new release such that (a) the barrier to being a release
manager is much lower and (b) we don't have accidental slips like not
having a Mantis tag for the release. (ChrisC, I keep mentioning this
not because it's a big deal - it's really not - but just because it's
a nice simple example.)

Having said that, we _should_ start a conversation around what will
become Squeak 4.4.

I'd like to see a greater emphasis on modularity, myself: if not
having Environments in the base image now, then at least identifying
the worst entanglements and working on cutting those. And tests.
Tests, tests, tests. The tools especially need some kind of framework
within which to test. A mock environment permitting one to test lovely
things like #removeClass would be fantastic. (There are building
blocks all over the place, but nothing assembled in the base image.)

frank

> There is also ReleaseBuilder which *should* provide the exact method
> to run against the last alpha which will configure and save it as the
> new final release.  That is how I did 4.2.
>
> HTH,
>   Chris
>