view doc/devel/versions.txt @ 7:57b2cc9b87f7

Use memcpy instead of strncpy when we know the length anyway. Modern gcc seems to think it knows how to detect misuse of strncpy, but it's wrong (in fact: very, very wrong) and the path of least resistance is to not try to fight with it.
author David A. Holland
date Mon, 30 May 2022 23:47:52 -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.