[Info-vax] VAX VMS going forward

[Bob Wilson]

On Thursday, July 23, 2020 at 4:03:40 PM UTC-4, Dave Froble wrote:
> On 7/23/2020 2:18 PM, Bob Wilson wrote:
> > On Wednesday, July 22, 2020 at 12:08:21 AM UTC-4, Michael Moroney wrote:
> >> Bob Wilson <bwandmw at gmail.com> writes:
> >>
> >>> There were in fact post-V7.3 full VAX VMS system builds done. It was never
> >>> explicitly stated that there would no longer be any VAX VMS releases, so....
> >>> the build & release team has to make sure that at least the build infrastructure
> >>> works even though the output is totally broken. We actually were down to
> >>> "quarterly builds" for that reason.
> >>
> >>> Also *many* checkins were done [by conscientious engineers who maintained
> >>> facilities that were common between the VAX and Alpha architectures...they/we
> >>> never got the word to stop] (I got emails for each one, so I can assure you
> >>> that there were non-remedial post-V7.3 checkins).
> >>
> >> Emerald, correct? Supposed to be V7.4?
> >>
> >> Wasn't that something that got cancelled as 8.x started to come out, or as
> >> part of the Alphacide? [killing off VAX as well] Or was it always unofficial?
> >
> >
> > I did a bit or archeology and without quite a bit more it's kinda hard to develop a time line for what was done when, but...
> >
> > Yes, EMERALD was to be V7.4 on both VAX and Alpha (though the initial version number assigned when the infrastructure for a release is first set up may or may not be the one that the release ships when it's complete).
> 
> Is there any easy way to mention what was in EMERALD that wasn't in V7.3 ?
> 
> -- 
> David Froble                       Tel: 724-529-0450
> Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA  15486

ROTFLOL :-)

Seriously, it would be possible but I have a job to do. And it would only be a list of modules from which you'd have to divine the intent of whoever did the checkin (some checkin comments can be, uh, brief).

Generally you'd have 1) bug fixes, 2) new functionality or 3) remedial fixes that propagate into the development stream.

The changes for EMERALD, given it's place and time, would be mostly 1 and 3 (which are both, in general terms, bug fixes). The stream for the next release is set up well before the next-release-to-go-out-the-door is done (as a place to put stuff that's deferred: "good ideas that may or may not pan out and we don't want to subject the next-release-to-go-out-the-door to the instability" [or for other reasons]). 

The presence of a stream did not imply that there was a manager for that stream, who job it would be to define the release based on the proposals for new functionality (solicited from engineers, product management, support groups, etc.)

I don't remember anyone being assigned to be the release manager for EMERALD (possibly a faulty recollection).