Thread: PostgreSQL v7.1BETA3 Bundled and Available ...
After almost a month since Beta1 was released, and skipping Beta2, the
PostgreSQL Developers are pleased to announced Beta3 of v7.1.
Due to the large number of changes made since Beta1 was released, we have
included a Changelog file detailing all changes, that is viewable in the
ChangeLogs subdirectory. This file is available outside of the
distribution at:
ftp://ftp.postgresql.org/pub/ChangeLogs/ChangeLog-7.1beta1-to-7.1beta3
Altho we anticipate at least one more beta release before full release, we
would like to encourage as many people as possible to download and test
out this version on their various platforms. All problems should be
report to pgsql-bugs@postgresql.org ...
The tar files can be downloaded from:
ftp://ftp.postgresql.org/pub/dev/..
All mirror sites should have copies of this within the next 24 hours ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker writes: > Due to the large number of changes made since Beta1 was released, we have > included a Changelog file detailing all changes, that is viewable in the > ChangeLogs subdirectory. Shouldn't that be in the HISTORY file? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, 11 Jan 2001, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > Due to the large number of changes made since Beta1 was released, we have > > included a Changelog file detailing all changes, that is viewable in the > > ChangeLogs subdirectory. > > Shouldn't that be in the HISTORY file? ChangeLogs is meant to be more detailed then HISTORY, for those that would like to see results similar to 'cvs log', but without cvs access ...
The Hermit Hacker writes: > ChangeLogs is meant to be more detailed then HISTORY, for those that would > like to see results similar to 'cvs log', but without cvs access ... In that case it would be more useful (and customary) to put the complete ChangeLog (since the beginning of time) into *one* file called 'ChangeLog'. (The version bumps will be apparent since some file will be changed to reflect it.) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Fri, 12 Jan 2001, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > ChangeLogs is meant to be more detailed then HISTORY, for those that would > > like to see results similar to 'cvs log', but without cvs access ... > > In that case it would be more useful (and customary) to put the complete > ChangeLog (since the beginning of time) into *one* file called > 'ChangeLog'. (The version bumps will be apparent since some file will be > changed to reflect it.) Thought of that, tried it, the resultant file was *humongous* with all of the TODO changes and such ... what I included was a cvs2cl.pl of just those changes since REL7_1 was tag'd, with a manual cleaning of the "TODO updated" lines ...
The Hermit Hacker writes: > > > ChangeLogs is meant to be more detailed then HISTORY, for those that would > > > like to see results similar to 'cvs log', but without cvs access ... > > > > In that case it would be more useful (and customary) to put the complete > > ChangeLog (since the beginning of time) into *one* file called > > 'ChangeLog'. (The version bumps will be apparent since some file will be > > changed to reflect it.) > > Thought of that, tried it, the resultant file was *humongous* with all of > the TODO changes and such ... what I included was a cvs2cl.pl of just > those changes since REL7_1 was tag'd, with a manual cleaning of the "TODO > updated" lines ... Those that like to see something similar to 'cvs log' are surely not interested into just the changes since beta 1 but at least since the branch from 7.0. If we're going to have a new changelog file for each subrelease-to-subrelease then it's not going to be useful. Maybe make ChangeLog_7_1, later ChangeLog_7_2, then ChangeLog_7_3 and remove ChangeLog_7_1, so you make a reasonable compromise between storage space and preserving the traditional nature and functionality of ChangeLogs. Should be under doc/ too, I think. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> The Hermit Hacker writes:
>> ChangeLogs is meant to be more detailed then HISTORY, for those that would
>> like to see results similar to 'cvs log', but without cvs access ...
> In that case it would be more useful (and customary) to put the complete
> ChangeLog (since the beginning of time) into *one* file called
> 'ChangeLog'.
Said file would currently amount to about 2.6 megabytes (I know,
I had occasion to do a complete cvs2cl.pl run earlier this week).
And the long-term trend is up.
I submit that that's too much to stuff into the distribution.
I think it's reasonable to make the changelog available on the
website (broken down into per-version segments, probably). I just
have doubts about forcing people to download it whether they
want it or not.
regards, tom lane
Tom Lane writes: > I think it's reasonable to make the changelog available on the > website (broken down into per-version segments, probably). I just > have doubts about forcing people to download it whether they > want it or not. I agree that the complete changelog is probably too long, I'm just against the per-version segmenting. Changelogs are usually used (well, by me) to get an overview when and how segments of code were worked on. The primary key here is not what (sub-)version the change happened in. The people that look into this sort of thing probably use cvs or snapshots, and even if not it makes the assumption that they downloaded and used *all* intermediate releases and only those, otherwise reading the beta1-to-beta3 changelog is pretty pointless in terms of finding out what happened to the code. How about maintaining a file ChangeLog that goes back one year? Another issue with ChangeLogs is that there's an implicit assumption that they are up to date. These won't be. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> I agree that the complete changelog is probably too long, I'm just against
> the per-version segmenting. Changelogs are usually used (well, by me) to
> get an overview when and how segments of code were worked on. The primary
> key here is not what (sub-)version the change happened in. The people
> that look into this sort of thing probably use cvs or snapshots,
Well, if you have bothered to set up cvs access then you can run cvs2cl
for yourself and get exactly the (subset of) the changelog you want.
My understanding of what Marc had in mind was to provide info for people
who only download releases and want to know what happened since the last
release they had.
The whole project might be a waste of effort though, since those folks
are likely to only want the digested HISTORY file and not the
blow-by-blow logs ...
regards, tom lane