Bug fixes only branch.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug fixes only branch.

Syed Ahmad
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug fixes only branch.

Donald Griggs
Hi, Syed,

===============================
On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad <[hidden email]>
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug fixes only branch.

Donald Shepherd
On Tue, 14 Jan 2020 at 7:00 am, Donald Griggs <[hidden email]> wrote:

> Hi, Syed,
>
> ===============================
> On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad <[hidden email]>
> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug fixes only branch.

Keith Medcalf
In reply to this post by Donald Griggs

On Monday, 13 January, 2020 15:00, Donald Griggs <[hidden email]> wrote:

>On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug fixes only branch.

Richard Hipp-3
In reply to this post by Syed Ahmad
On 1/13/20, Syed Ahmad <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users