Mercurial > ~dholland > hg > ag > index.cgi
view doc/devel/versions.txt @ 6:607e3be6bad8
Adjust to the moving target called the C++ standard.
Apparently nowadays it's not allowed to define an explicit copy
constructor but not an assignment operator. Consequently, defining the
explicit copy constructor in terms of the implicit/automatic
assignment operator for general convenience no longer works.
Add assignment operators.
Caution: not tested with the IBM compiler, but there's no particular
reason it shouldn't work.
author | David A. Holland |
---|---|
date | Mon, 30 May 2022 23:46:22 -0400 |
parents | 13d2b8934445 |
children | 12171da8943f |
line wrap: on
line source
Theory of AG version numbers (as of 20060806, updated 20070603, 20070613) - Any version of AG has a "base version number". This is 2.01 for 2.01, 2.40 for the first public open source version, 2.50 for the stable open source version, and 3.00 for the first GTK version, whenever that appears. This version goes into the Windows registry. - Development snapshots leading up to the first release with a particular base version number are numbered with the new base version, a dash, and the date or a release candidate number. Examples: 2.40-20070610; 2.40-RC2. - Stable versions have the base version followed by a dot and the build number, aka patchlevel. For example: 2.40.01. - Every changeset committed to the stable branch causes a new build and increments the build number. Needless to say, you don't commit to the stable branch lightly. - A development version built directly from a CVS or Mercurial working directory will be numbered 2.40-current, because it's difficult or impossible to ascertain the proper date. Assuming the proper date is even well defined. - A stable version built directly from a CVS or Mercurial working directory will be numbered 2.40.01-current. - If we set up anoncvs, which if properly managed is equivalent to issuing a devel snapshot every night, it should be possible to inject the date.