Early version 3.49.0?

(1.1) By Richard Hipp (drh) on 2025-02-01 19:24:54 edited from 1.0 [source]

We were planning to do a patch release 3.48.1 to fix various minor problems discovered in 3.48.0, today (Saturday) or Monday. But, I thought, the trunk is stable, why not just go ahead and do a full-up 3.49.0 release that includes recent enhancements? It has been less than a month since 3.48.0. Our normal major release cadences is in the 5-to-7 month range. But is there really any harm in doing two back-to-back major releases in less than 30 days?

I currently have draft documentation up at:

A tentative release date of 2025-02-06 (Thursday) was chosen, but that is subject to change.

Is this a good idea? A bad idea? Should I proceed with doing a 3.49.0 release that includes enhancements, or just do a 3.48.1 patch release that contains only bug fixes? What do y'all think?

(2) By Aask (AAsk1902) on 2025-02-01 19:21:22 in reply to 1.0 [link] [source]

Should I precede with doing a 3.49.0 release that includes enhancements,

(Assuming that by precede you actually meant proceed) From my point of view, yes.

3.48 would not have gathered any momentum in the short time since its release
will avoid the overhead of grappling with 3.48 issues when upgrading to the latest SQLite3 release ... which will become 3.49.

(3) By Anton Dyachenko (ahtoh_) on 2025-02-01 19:30:28 in reply to 1.0 [link] [source]

I usually do not chase the latest features but prefer most bug free releases. This is in general not just SQLite. So my default strategy is search for the latest minor release major.minor.patch then find one previous - with the highest patch number.

More simplified strategy I follow is avoid releases which version's last number is 0.

(4) By Richard Hipp (drh) on 2025-02-01 19:47:19 in reply to 3 [link] [source]

I understand that. Part of the reason for branch-3.48 is to have a release that contains only bug fixes. But in this case, the total amount of change for the proposed 3.49.0 is not much more than the bug fixes in 3.48.1. And, a major release like 3.49.0 goes through much more rigorous testing than a patch release like 3.48.1. So at least for this case, I don't see any advantage to 3.48.1. That's why I'm proposing the jump directly to 3.49.0.

(5) By Mike Castle (nexushoratio) on 2025-02-01 20:02:01 in reply to 1.1 [link] [source]

In general, I prefer to see new full releases more often (e.g., monthly), with fewer patch releases.

(6) By Anton Dyachenko (ahtoh_) on 2025-02-01 22:42:08 in reply to 4 [link] [source]

Basically the question is does small number of features in 49 is low risk to combine them with bug fixes and save some time/resources and skip patch release. I don't know how expensive a patch release and how confident you are in your risk estimatetion. I usually prefer to follow established process unless a good reason for an exception.

(7) By Richard Hipp (drh) on 2025-02-01 23:26:19 in reply to 6 [link] [source]

You can do whatever you want of course.

Another big issues is there were three reports of performance regressions for some large and complex joins over the past month or so. Those performance regressions are fixed in 3.49.0, but because they are not technically "bugs" (because they still generate the correct answer, just slower than people would like) the fix is not included in 3.48.1. So by jumping directly to 3.49.0 instead of doing 3.48.1, more pending issues are resolved.

(8) By Balaji Ramanathan (balaji) on 2025-02-02 03:03:34 in reply to 1.1 [link] [source]

I vote for any version that fixes the regressions introduced in 3.47 and 3.48. Since those regressions made those versions unusable for me, my previous major release was 3.46 from May of 2024. So, the release of 3.49 in February of 2025 already exceeds the 5-7 month cadence as far as I am concerned.

(9) By anonymous on 2025-02-02 09:42:23 in reply to 1.1 [link] [source]

Dr. Hipp,

I'm a clueless nobody, so maybe you should just ignore this, but I'll think out loud for a moment in case there's any use in it.

I'm guessing the situation is like this: if you decide to kick off a major release it would need to be pretty quick. The longer you wait the more people grab 3.48, whereas if you ship right away many external users would just pass right over it. Furthermore waiting could make it more awkward to embark on any pending major new feature work, if you felt pressured to keep such work strictly off in side branches so trunk could stay pristine for a pending release. So the crux is probably that you need to make up your mind without too much delay?

The case for "yes" is you get those performance regressions out of the way immediately, rather than possibly having more people over the next few months stumble into similar trouble. The case for "no" would seem chiefly to boil down to... "We don't usually do things this way." My feeling is twofold. I admire this project for being steady and predictable amidst the chaos of life. At the same time, I also admire it when once in a blue moon people exercise some situational judgment and make exceptions to routine, refusing to make habit into stone tablets from Sinai.

However one potential legit argument I can see for "not quite yet" is that 3.48 was kind of a special release. It's not that often you have a wholesale change in build tooling. The advantage of waiting a little longer is more opportunity for corner-case bug reports to possibly come in, and you'd still have the flexibility of shipping a new major if your preferred response might be something uncomfortable for a patch update. The crux though is you could maybe delay it another week or two, but I'd guess you won't want to stay in a "release ready holding pattern" for too much longer.

So the essential question would seem to be: Is there any way in just the next week or two to prompt some feedback from SQLite users who might not yet have tested 3.48? I'm guessing you've probably already beta tested this stuff privately with your commercial users. Are there any academic mailing lists or forums full of people who use SQLite in interesting ways? Computer Science professors, high finance people, anything like that? Or just post a one-off testing request to Hacker News?

I'll answer my own question. Unless something obvious jumps out to you, I'm guessing this whole line of thinking is probably just me chasing ghosts. Staying in a release holding pattern for a week or few just in case new bug reports might possibly come in would probably end up being a waste of time. Most likely if bug reports do trickle in, it's probably stuff you would fix via a patch release anyway, so delaying the major release would be pointless. That's probably the realistic answer.

So I guess, why not cut loose and go for 3.49 this week? Tell everyone it's your version of a mid-life crisis. You know like when Bruce Dern buys the Porsche 928 in that cheesy "Middle Age Crazy" movie? When other guys start feeling the years piling up, they buy a Porsche or a Corvette or a ski boat. When Richard Hipp feels the grips of his mortality, he starts releasing new versions of SQLite like a madman. I like that story! :-)

(10) By Simon Slavin (slavin) on 2025-02-02 13:51:49 in reply to 1.1 [link] [source]

I have concerns with

https://sqlite.org/draft/c3ref/c_dbconfig_defensive.html

which may have originated before this new version added to it.

First "the the this". At least that one is easy to describe. Phew.

Second, the section 'Arguments To SQLITE_DBCONFIG Options' could be moved before the list of options, and I have a problem with it.

Most of the SQLITE_DBCONFIG options take two arguments: an integer and a pointer to an integer. If the first integer argument is 1, then the option becomes enabled. If the first integer argument is 0, then the option is disabled. If the first argument is -1, then the option setting is unchanged. The second argument, the pointer to an integer, may be NULL. If the second argument is not NULL, then a value of 0 or 1 is written into the integer to which the second argument points

I'm as confused about this as when people try to explain the offside rule without first telling me why it exists. I understand the words but not why they're necessary. How many integers can the second argument point to, and how does it point to one of them ? Why would you want to change one of them in any way other than what can be done with the first argument ? Basically, what is this for ?
If you explain the two arguments here, you don't need to keep explaining them in each of the options.

Third, the relationship between SQLITE_DBCONFIG_ENABLE_ATTACH_CREATE and SQLITE_DBCONFIG_ENABLE_ATTACH_WRITE. One disables the other. They're obviously related. Would it not be more sensible to instead make a SQLITE_DBCONFIG_ATTACH_ABILITIES which can be none / write / create ? You could also add more: none / read / write / change_schema / create.

Last, a question. What's SQLITE_DBCONFIG_ENABLE_COMMENTS about ? Is it to protect against possible vulnerabilities which may be supposed even if nobody has ever seen one and the devs can't imagine how one would work ? Or does it make SQLite faster ? Or is there some strict version of SQL which doesn't allow comments ?

(11.2) By Stephan Beal (stephan) on 2025-02-02 14:33:45 edited from 11.1 in reply to 10 [link] [source]

Third, the relationship between SQLITE_DBCONFIG_ENABLE_ATTACH_CREATE and SQLITE_DBCONFIG_ENABLE_ATTACH_WRITE. One disables the other.

CREATE implies WRITE, whereas WRITE does not imply CREATE. With the CREATE flag it's possible to create a non-existing db by ATTACHing it (which has long been the default behavior and will remain so). WRITE, which is the default, can be set to 0 to disallow writing to ATTACHed databases. Why would you want that? Jump to the last line of this post for the answer.

Would it not be more sensible to instead make a SQLITE_DBCONFIG_ATTACH_ABILITIES which can be none / write / create ? You could also add more: none / read / write / change_schema / create.

Fair point, but let's hope that it doesn't come to that degree of granularity.

What's SQLITE_DBCONFIG_ENABLE_COMMENTS about?

One of the benefits of SQLite Consortium membership is that feature requests are likely to be implemented.

(12) By Nuno Cruces (ncruces) on 2025-02-02 23:27:01 in reply to 10 [link] [source]

I understand the words but not why they're necessary.

I'll take a stab, but I have to confess I had no trouble with either the words or their meaning.

Most SQLITE_DBCONFIG are boolean settings: either enabled (true) or disabled (false). Booleans in C are represented as integers zero is false, non-zero (typically, one) is true.

This API allows updating the boolean, or querying the boolean.

To set it to false, the first integer is zero. To set it to true, the first integer is one.

To query the current value without changing it, use -1 (minus one). This doesn't change the value.

To read the value back you need a pointer. Why? Because the return value is taken for an error code. So you need to pass a pointer to a boolean (aka integer) and SQLite writes the new value there (zero/false or one/true). If you don't care about the new value, you can pass NULL.

But this is just restating the docs, so I'm not sure it helps.

(13) By Nuno Cruces (ncruces) on 2025-02-02 23:31:13 in reply to 1.1 [link] [source]

I like majors, because for majors there's usually a clear cut commit that can be used from the bedrock branch.

For minors the corresponding commit is often less clear (or non existent).

(14) By anonymous on 2025-02-03 07:49:35 in reply to 12 [link] [source]

Bravo! At least to my mind, that is much clearer.

(15) By Simon Slavin (slavin) on 2025-02-03 12:59:56 in reply to 14 [link] [source]

Yeah, me too. Start off by saying the second parameter is for reading the value. Then I know why I'm suddenly reading about pointers.

(16) By Simon Slavin (slavin) on 2025-02-03 13:01:02 in reply to 11.2 [link] [source]

Thanks for the answers. They explain a lot.