[V3dot10] Going to beta ?

[Ralph Johnson]

My interpretation of "going to beta" means that we stop adding
features and just fix bugs.  I am in favor.

There is only one more feature that I want to add.  This is a change
to the VersionsBrowser.  You can see an early version of it at
http://swiki.cs.uiuc.edu/cs598rej/315

In brief, the idea is to change the way source code is represented.
Right now the .sources file has the "original" version of each method,
and the .changes file has all the versions since then.   We have
modified this with a history database, which contains versions of
methods OLDER than the .sources file.  So, the .changes file still has
all the versions since the .sources file.  Most of the system has not
changed.  Only the versions browser changed.  However, this will let
us condense all changes into the .sources file WITHOUT losing any
history.

Edgar, we will deliver this feature as a MC file, so you don't have to
convert a .cs to a .MCZ.  In fct, I can make the final alpha release
if you don't want to.

One of the features of the new versions browser that doesn't yet work
is for the history database to be remote.  Right now, the history
database is a directory of files, one for each class in the database.
My plan was for this to be put on a server and that people who didn't
need to browse version history very often, or who were short on disk
space, could just use the remote version.  That doesn't work yet,
though it might work in a few days.  However, everything else seems to
work, though it hasn't been tested very much.

Here is what I am thinking.  For our final alpha image, we will
provide a history database, a new .sources file, and a completely
empty changes file.  During the beta process, we will keep using the
history database and the .sources file, (unless we discover something
wrong with them).  Then, for the final 3.10 release, we will once
again rebuild the history database and .sources file, and have an
empty changes file.

The 3.9 team ran out of space in the .changes file and had to condense
changes, losing some history.   It would be cool to go back and
recover that history and put it in the history database.

Even cooler, we could go back and get all the history in Squeak 1 and
Squeak 2, so we could have a complete history of all code that had
ever been in the Squeak image.  This would only require changing the
history database, not changing anything in the image, so it is outside
the official 3.10 release process.  If we don't have time to work on
it earlier, we could work on it after 3.10 is over.

The new versions browser has a much nicer way of representing the
sources than what Squeak currently has.  We should considering
refactoring Squeak to use these classes everywhere.  However, I am
opposed to doing that in 3.10.   We should use the new versions
browser and debug these classes.  Once these classes are mature than
we can change other tools to use them, perhaps in 3.11 or 3.12.

This work was done by Maurice Rabb and Navodit Kaushik as a class
project for my course on OO programming and design.  Navodit will be
the first to admit that Maurice was the leader on this project.  He is
a long-time Smalltalker who is just starting grad school at UIUC and
you can expect to hear a lot from him in the future!

So, here is a summary of my proposal.  I want to know what you think about it!

We will make the final 3.10 alpha be to add the new versions browser,
and the final alpha image will have a new history database, a new
.sources file and an empty changes file.  If you update your old image
to have all the changes then you will still have the old .sources file
and the old .changes file and the history database won't be much use
to you.  We might not have the remote history database working.  We
should be able to do this within a week.

During the beta period we will just fix bugs.  One of those bugs might
be the fact that the remote history database doesn't work.

The final 3.10 release will have a new .sources file and a new history database.

-Ralph