Squeak release process

Hi,

After the recent chat between Alexander Lazarević and Chris
Cunnington, 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
there isn't one, we really ought to write one. If there isn't an
automated "make a new tag on Mantis for the release" script we can at
least have a "nag a Mantis admin to make a release" item.

frank

(*) No, I'm not volunteering for releasing 4.4! Sorry :/

On 7/16/12 6:59 AM, "Frank Shearar" <[hidden email]> wrote:

Seems the job Ralph and me was unnoticed

See http://wiki.squeak.org/squeak/5919 and several more related.
Once we have a Release Team and for no good reasons we don't have one now.
So Squeak is on comatose and few care about.

Edgar

On 16 July 2012 12:03, Edgar J. De Cleene <[hidden email]> wrote:
Hi Edgar,

I saw several such pages. Those tell me what went into 3.10, 4.3, etc.
I'm not talking about those. I'm talking about a checklist that anyone
can follow to produce/manage a new Squeak release. For example
* Warn of a code freeze no later than 4 weeks before the due release date
Pre-release planning and announcements
* Ensure that all tests pass. Any failing tests that cannot be fixed
marked as expected failures
* and
* so
* on
Release time
* Add a new category to Mantis for the release
* Prepare release notes, published to squeak-dev for comment. In the
absence of comments, assume that the notes are fine.
* Publish the artifacts to ___.
Post-release cleanup
* Unmark the expected failures marked earlier, so someone can actually fix them

Also, of course we have a release team. We just don't have a
_dedicated_ release team. And we shouldn't, for good reason: a
dedicated release team is an excuse for everyone else to assume that
the release team bears full responsibility for the process.

frank

> Edgar
>
>
>

On 7/16/12 8:10 AM, "Frank Shearar" <[hidden email]> wrote:

All you said was the process followed...
And a dedicated release team is not excuse for people wishing a better
Squeak.

Edgar

On 16 July 2012 12:27, Edgar J. De Cleene <[hidden email]> wrote:
I think we're not talking about the same thing. I would like to see a
checklist that a release team can follow. I don't know where I can
find such a checklist. There might be one buried on the Swiki, but I
couldn't find it.

frank

> And a dedicated release team is not excuse for people wishing a better
> Squeak.
>
> Edgar
>
>
>

On Mon, Jul 16, 2012 at 12:40:34PM +0100, Frank Shearar wrote:
>
> I think we're not talking about the same thing. I would like to see a
> checklist that a release team can follow. I don't know where I can
> find such a checklist. There might be one buried on the Swiki, but I
> couldn't find it.

I think you're right, and it is important to have this. IIRC the
information is going to be in various emails on this list, and possibly
also on the dedicated lists that were used in previous releases. If
that information can be captured in the form of a checklist as you
suggest, that will be very useful.

Dave

> ... 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

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

On 19 July 2012 23:00, Chris Muller <[hidden email]> wrote:
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
>