Re: [sqlite] Bug fixes only branch.
On 1/13/20, Syed Ahmad wrote: > We are at 3.14.2 > > Current version = 3.14.2 Date : 2016-09-12 > > https://www.sqlite.org/changes.html > > how can i take latest stable branch which include only bug fixes . no new > features. > > Is there any way? We sometimes do things like that for paid support customers. But maintaining bug-fix branches of historical versions is time-consuming, so we do not do it routinely. It is also risky, as actual releases are better tested and more reliable than backported patches. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug fixes only branch.
On Monday, 13 January, 2020 15:00, Donald Griggs wrote: >On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad >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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug fixes only branch.
On Tue, 14 Jan 2020 at 7:00 am, Donald Griggs wrote: > Hi, Syed, > > === > On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad > 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? > Since the sqlite team spends so much effort to ensure backward > compatibility, how bad would things be if you simply updated to the current > stable release? > > The team does allow many features to be eliminated through conditional > compilation if you are severely constrained in RAM. Was RAM size the > motivation? > > To provide versions which include only bug fixes from any arbitrary > releasee, I should think the developers would, for every stable release, > have to maintain a new fixes-only branch indefinitely -- and thus have to > maintain dozens of branches. Am I missing something? > > Kind regards, >Donald > ___ I can't speak to his exact scenario but having spent time in a very risk averse work environment, I've experienced this kind of thinking. The logic is almost always as a result of "we must have low bug counts (true) so we need bug fixes (true) but new features introduce bugs (in general true) therefore we don't want any new features". In other words it's a result of the environment rather than a reflection of SQLite. Regards, Donald Shepherd. > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug fixes only branch.
Hi, Syed, === On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad 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? Since the sqlite team spends so much effort to ensure backward compatibility, how bad would things be if you simply updated to the current stable release? The team does allow many features to be eliminated through conditional compilation if you are severely constrained in RAM. Was RAM size the motivation? To provide versions which include only bug fixes from any arbitrary releasee, I should think the developers would, for every stable release, have to maintain a new fixes-only branch indefinitely -- and thus have to maintain dozens of branches. Am I missing something? Kind regards, Donald ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Bug fixes only branch.
We are at 3.14.2 Current version = 3.14.2 Date : 2016-09-12 https://www.sqlite.org/changes.html how can i take latest stable branch which include only bug fixes . no new features. Is there any way? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
