On Monday, 13 January, 2020 15:00, Donald Griggs <[email protected]> wrote:
>On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad <[email protected]> >wrote: >> We are at 3.14.2 Date : 2016-09-12 >> how can i take latest stable branch which include only bug fixes . no >> new features. >> Is there any way? > I may well not be understanding properly, but what motivates you to ask > for this? I would suspect that the motivation is a periodic risk re-assessment policy that has been either badly written or is being badly interpreted in the belief that the addition of "new features" that are unused to a component that is subject to risk assessment requires an assessment of the risk associated with the unused "new features". In other words, the risk assessment is based on the version of something rather than the utilized functionality of something. This is quite common and in my previous job (before retirement) significant resources were spent on unnecessarily re-assessing things just because the version number changed (which often meant that things were not updated in order to prevent this expensive process), rather than simply reviewing the existing Risk Assessment and determining that nothing had changed, and that the addition of new unused "features" was immaterial to the overall assessment. That is, someone had generated a Risk Assessment based (for example) on the use of SQLite version 3.14.2 and that the mere act of updating the version triggers the process for the re-evaluation of the Risk of the new version in toto, including the Risk associated with "features available" rather than "features used", when in fact the update of the version (and the addition of new unused and inaccessible features) was quite irrelevant. A significant amount of effort was expended globally (probably on the order of hundreds of thousands of man-hours at not insignificant engineering cost per hour) to remove "version numbers" from Risk Assessments and to make sure that they were based on functionality used/exposed rather than the version number itself. In this example, the difference is that someone believes that (for example) because the current version of SQLite supports CTE's and the old one didn't, requires an assessment of the risk associated with CTEs, even though the specific use being assessed does not and cannot use CTE's, thus triggering a full assessment of Risk (including the unused CTE feature) rather than merely a review to determine whether or not there been any significant change to the risk profile which would require re-assessment. In other words, if the "old" version of something only supported "red" and "blue", and the system only used "red", and a subsequent version added "green" without affecting the functionality of "red" (and that "blue" and "green" are not used and cannot be accessed) then the mere fact of the addition of the feature "green" is irrelevant (until such time as the feature "green" is used, of course). The fact that the new thing "green" is available is merely a quaint observation of zero significance if (a) it is not used and (b) cannot be meaningfully accessed, and its addition is not a significant change to the risk of that something. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
