Revision: 73048
http://sourceforge.net/p/brlcad/code/73048
Author: starseeker
Date: 2019-05-13 13:09:32 +0000 (Mon, 13 May 2019)
Log Message:
-----------
Update HACKING description for errata release conventions.
Modified Paths:
--------------
brlcad/trunk/HACKING
Modified: brlcad/trunk/HACKING
===================================================================
--- brlcad/trunk/HACKING 2019-05-13 00:09:01 UTC (rev 73047)
+++ brlcad/trunk/HACKING 2019-05-13 13:09:32 UTC (rev 73048)
@@ -1082,11 +1082,8 @@
{MAJOR_VERSION}.{MINOR_VERSION}.{PATCH_VERSION}
All "development" builds use an odd number for the minor version. All
-"release" builds use an even number for the minor version. Patched
-versions should include a release count:
+"release" builds use an even number for the minor version.
- {MAJOR_VERSION}.{MINOR_VERSION}.{PATCH_VERSION}[-{RELEASE_COUNT}]
-
The MAJOR_VERSION should only increment when it is deemed that a
significant amount of major changes have accumulated, new features
have been added, or enough significant backwards incompatibilities
@@ -1107,11 +1104,15 @@
version number.
If it becomes necessary to update a posted release, use and increment
-the RELEASE_COUNT. The first posted release is implicitly the "-0"
-release count (e.g., 7.10.2 is implicitly 7.10.2-0) with subsequent
-updated releases incrementing the count (e.g., 7.10.2-1).
+the ERRATA_COUNT format outlined below. The first posted release is
+implicitly the "-0" release (e.g., 7.10.2 is implicitly 7.10.2-0) with
+subsequent updated releases incrementing the count (e.g., 7.10.2-1).
+See the "ISSUING AN ERRATA" section below for guidelines on when an
+errata update should be used in lieu of a new PATCH_VERSION release.
+ {MAJOR_VERSION}.{MINOR_VERSION}.{PATCH_VERSION}[-{ERRATA_COUNT}]
+
NAMING A SOURCE RELEASE
-----------------------
@@ -1203,33 +1204,42 @@
zip
-PATCHING A RELEASE
-------------------
+ISSUING AN ERRATA UPDATE TO A RELEASE
+-------------------------------------
-Should it become necessary to patch a release that has already been
-posted and announced, the mechanism is to post patch files for the
-source release and update the uploaded release notes README file.
+There are occasionally situations that arise in the release process
+where immediately after the tagging and archive uploading a flaw is
+identified in the tagged release. If the corrective change can be
+succinctly expressed as a small update to the source code, the
+update is posted as a patch file for the source release and the
+uploaded release notes README file is adjusted to instruct users
+building from source code to first apply the patch file or files.
+It's expected that all errata patch files are independent and will be
+applied sequentially. They should be consistently and incrementally
+numbered. Users should be instructed in the release notes README to
+download and apply all available patch files.
+
Example: stop_rt_crashing-0.patch and fix_fbserv-1.patch
-It's expected that all patch files are independent and will be applied
-sequentially. They should be consistently and incrementally numbered.
-Users should be instructed in the release notes README to download and
-apply all available patch files.
+If it becomes necessary to repost a release, use the ERRATA_COUNT
+file name convention described in VERSION NUMBERS & COMPATIBILITY.
-For binary releases, it's recommended to just "move on" and let issues
+Example: BRL-CAD-7.12.2.dmg is superseded by BRL-CAD-7.12.2-1.dmg
+
+For binary builds, it's recommended to just "move on" and let issues
become resolved in the next release unless there's a critical security
-or significant data corruption issue involved. If it becomes
-necessary to repost a release, use the RELEASE_COUNT file name
-convention described in VERSION NUMBERS & COMPATIBILITY.
+or significant data corruption issue involved. If it is necessary to
+update the binary, the CMake variable BRLCAD_VERSION_ERRATA may be
+defined at configuration time to propagate the errata version number
+through the build. BRLCAD_VERSION_ERRATA should be set to match the
+highest errata patch file number applied to the source tree.
-Example: BRL-CAD-7.12.2.dmg is superseded by BRL-CAD-7.12.2-1.dmg
-
-Patched binary releases may be moved to the hidden attic folder if
+Older binary releases may be moved to the hidden attic folder if
critical, though not necessary or recommended. They are preserved for
historic record and should never be deleted once announced. Releases
-not yet been announced may be updated within two days of being posted
-without involving a patch.
+which have not yet been announced may be updated within two days of
+being posted without involving a errata update.
MAKING A RELEASE
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits