[Squeakfoundation]Re: 3.5 release timing

[Doug Way]

Craig Latta wrote:
> 
> Hi Doug--
> 
> > We would need to put some limits on the number and kind of bugfixes
> > that are accepted...
> 
>         Indeed; ideally a release version has a list of scheduled features
> attached to it *before* any work starts. I think we should strive for
> that. I think "Squeak 3.5" should evoke a very concrete list of changes,
> as opposed to merely a guideline about the kind of change that will be
> accepted. The latter just invites last-minute submissions, dragging out
> the release process.

Generally agreed.  If this were a "normal" release, we wouldn't be able to
predict all of the many bugfixes which would typically go into the release,
but a list of the major new features/enhancements is something we should try
to settle on beforehand, yes.

With 3.5 though, since bugfixes are the only content of this short release, it
might not be a bad idea to have a list of proposed bugfixes beforehand.

(I think in the case of 3.4 being released, things were generally a bit
chaotic, and I just wanted to get 3.4 out the door before worrying too much
about 3.5. :-)  But that will have to change for future releases.)

>         Also, ideally, the naming, feature-scheduling and timing for a
> particular version is finalized by the time of the previous version's
> release. At the latest, the discussion is finalized during the previous
> gamma (often having the useful side-effect of appeasing those whose
> not-quite-critical-enough submissions were deferred :). So, for example,
> I hope we can finalize the schedule for <the-release-after-3.5> by the
> time we release 3.5.

Agreed.

> In fact, I'd even go so far as to make the next
> release schedule an official feature of each release. :)
> 
>         If the 3.5 schedule were up to me...
> 
>         3.5 would include the project-writing fix, the class-builder fix, the
> next release schedule, and nothing else. I would set a release date of
> the next first-Friday (4 April), as it seems like a short cycle (since
> the principle writing seems to be finished).

I like this idea.  

It would limit the release to the couple of fixes which were the real reason
for the short bugfix release in the first place (making the short release
considerably safer), and it would shorten the 3.5 release to even less than 1
month, allowing us to move on with the next "normal" release sooner.

And it still buys us some time to discuss the content of the post-3.5 release
(and get a few other process issues worked out), so that we have a release
plan in place for the post-3.5 release before 3.5 is done.

> First Fridays are simple
> and memorable, and moving faster than monthly is both more difficult for
> the community to keep straight and not really feasible from a labor
> perspective. If possible, make sure the release is available by the
> stroke of midnight at the beginning of release day, GMT, to avoid
> timezone confusion (no one can say it's late :). If a release slips, go
> to the next first Friday; it's just simpler that way.

That doesn't sound like a bad idea, we could try that as a general rule.

> I wouldn't worry
> about having lots of small releases, you won't run out of minor numbers.
> :)  (E.g., the next minor release after 3.9 is 3.10, etc.)

About the only thing that's somewhat debatable here is whether this next
release (assuming a short bugfix release) should be called 3.5 or 3.4.1 as
Goran suggested, since for most practical purposes it is a "patch" release.

But the Squeak tradition has been to avoid tertiary release numbers (3.2.1
being an abberation), and most people have been calling it 3.5 so far, so I
wouldn't mind just calling it 3.5.

- Doug Way