SQLite version 3.8.12 enters testing

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

SQLite version 3.8.12 enters testing

Richard Hipp-3
The release checklist for version 3.8.12
(https://www.sqlite.org/checklists/3081200/index) is now active.  The
3.8.12 release will occur when the checklist goes all-green.

A preliminary change log for version 3.8.12 can be seen at
https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
documentation can be seen at https://www.sqlite.org/draft/

If you have issues or concerns with the current SQLite trunk, please
speak up *now*.

--
D. Richard Hipp
[hidden email]
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Jaroslaw Staniek
​ ​

On 7 October 2015 at 16:42, Richard Hipp <[hidden email]> wrote:

> The release checklist for version 3.8.12
> (https://www.sqlite.org/checklists/3081200/index) is now active.  The
> 3.8.12 release will occur when the checklist goes all-green.
>
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.
>
>
​Hi​,
​Thanks for the great work!

PS: I am sorry to repeat that once more but based on the extensive list of
new features in this "minor release": would you elaborate what​ is the
benefit of using x.y.z versioning scheme if so many new features come to
the "z" release? I've heard that "Users are expected to compile sqlite by
hand" but as we all know Linux distributions ship them and reject apps that
own a copy of SQLite. Then when some projects start to depend on features
that came in 3.8.12, distributions do not seem to care about that. Any
3.8.z is considered compatible. This is how 99.(9)% of software is
versioned.

For now users won't notice that <=3.8.12 is installed, and checking of that
is delegated to the each application's runtime or to the specific packaging
rules.

So is there any hope for 3.9 or 4.x to have more traditional versioning:
having a distinction between patch releases and minor releases, where only
the latter allows for new features?

SQLite evolves so quickly that I know we would have version like 3.40.z by
now. And that would be much better...


--
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-dev mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev
>



--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
_______________________________________________
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: SQLite version 3.8.12 enters testing

Dominique Devienne
In reply to this post by Richard Hipp-3
On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp <[hidden email]> wrote:

> The release checklist for version 3.8.12
> (https://www.sqlite.org/checklists/3081200/index) is now active.  The
> 3.8.12 release will occur when the checklist goes all-green.
>
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.
>

Could you please provide links to the amalgamation? TIA, --DD
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Richard Hipp-3
In reply to this post by Jaroslaw Staniek
On 10/7/15, Jaroslaw Staniek <[hidden email]> wrote:
> ​ would you elaborate what​ is the
> benefit of using x.y.z versioning scheme if so many new features come to
> the "z" release?

That's the versioning scheme that has been used by SQLite for 15
years.  Back when it was adopted, 15 years ago, it was certainly *not*
the case that 99.9% of software did something different.  In fact, 15
years ago, the current SQLite versioning scheme was rather common.

The community seems to want the second number (current 8) to increment
every time a new feature is added to SQLite.  I will take your request
under advisement.  Realize, however, that had the current preferred
number scheme been used for SQLite from the beginning, the next
release would be called 3.112.

--
D. Richard Hipp
[hidden email]
_______________________________________________
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: SQLite version 3.8.12 enters testing

Richard Hipp-3
In reply to this post by Dominique Devienne
On 10/7/15, Dominique Devienne <[hidden email]> wrote:
>
> Could you please provide links to the amalgamation? TIA, --DD

https://www.sqlite.org/download.html - the first link at the top of
the list of products.
--
D. Richard Hipp
[hidden email]
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Simon Slavin-3
In reply to this post by Richard Hipp-3

On 7 Oct 2015, at 4:39pm, Richard Hipp <[hidden email]> wrote:

> The community seems to want the second number (current 8) to increment
> every time a new feature is added to SQLite.  I will take your request
> under advisement.  Realize, however, that had the current preferred
> number scheme been used for SQLite from the beginning, the next
> release would be called 3.112.

To supplement Richard's answer ...

The three-number versioning scheme works like this.  Suppose your software is currently on version 2.2.2 .  The next version would be

2.2.3 -- purely a bugfix with no new features introduced
2.3.0 -- introduces a new feature (even if it fixes a bug too)
3.0.0 -- a major rewrite (whether or not it introduces new features)

This system is still in use in many software publishers.

SQLite doesn't use it in quite the same way because

(A) The parsing and optimization parts of SQLite are extremely complicated and can make it difficult to distinguish between a bug-fix and a minor new feature.
(B) The product itself is called SQLite3 so the '3' has to be fixed.  Major rewrites to SQLite to, for example, introduce WAL mode, can't change the '3'.

Simon.
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Richard Hipp-3
On 10/7/15, Simon Slavin <[hidden email]> wrote:
> (B) The product itself is called SQLite3 so the '3' has to be fixed.  Major
> rewrites to SQLite to, for example, introduce WAL mode, can't change the
> '3'.

The "3" is the file format.  SQLite1 and SQLite2 used different and
incompatible file formats.  SQLite 3.8.12 can read and write any
database made by any prior version of SQLite.  SQLite 3.0.0 can read
and write any database made by any subsequent version of SQLite, as
long as no new features (ex: common table expressions, partial
indexes) are used.  (In practice, so many new features have been added
since 3.0.0 that it will be difficult to find a real database that
3.0.0 can read and write, but it is possible in theory.)

--
D. Richard Hipp
[hidden email]
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Dominique Devienne
In reply to this post by Richard Hipp-3
On Wed, Oct 7, 2015 at 5:39 PM, Richard Hipp <[hidden email]> wrote:

> On 10/7/15, Jaroslaw Staniek <[hidden email]> wrote:
> > ​ would you elaborate what​ is the
> > benefit of using x.y.z versioning scheme if so many new features come to
> > the "z" release?
>
> [...] The community seems to want the second number (current 8) to
> increment
> every time a new feature is added to SQLite.  I will take your request
> under advisement.  Realize, however, that had the current preferred
> number scheme been used for SQLite from the beginning, the next
> release would be called 3.112.
>

That 3.112 version is a better reflection of all the changes in a way.

Minor version bumps are kinda arbitrary, why 3.8.12 and not 3.9.0 indeed.
Table-valued functions are a big enough change to warrant it IMHO, but
maybe that's just me. --DD
_______________________________________________
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: SQLite version 3.8.12 enters testing

Zsbán Ambrus
In reply to this post by Richard Hipp-3
On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp <[hidden email]> wrote:
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.

I have concerns with the documentation.

"http://sqlite.org/draft/changes.html" mentions "Added support for
indexes on expressions.", and points to
"http://sqlite.org/draft/lang_createindex.html" which tells that an
index row may contain an expression computed from the columns of the
table row.  This implies that an index could be ordered by such an
expression, or it could just cover such an expression if the previous
columns of that index determine the sort order uniquely.

However, I have not seen anything in
"http://sqlite.org/draft/optoverview.html" on how such an expression
column in an index can be used.  Section 1.0 in that document does not
seem to indicate that sqlite can use an expression index to satisfy a
WHERE clause involving an expression computed from a column.
According to section 6.0, this seems to imply that such indexes also
cannot be used to satisfy the ON clause of a JOIN.  Section 8.0
mentions only columns, so I can't tell whether sqlite will use the
expression column of an index to get the value of a result-column
expression of a SELECT from the index, without having to get the value
of the columns involved in the expression from the table, if those
columns aren't in the index.  Section 9.0 seems the most vague, I
can't tell from that whether sqlite can use an index on an expression
to speed u pa SELECT with an ORDER BY clause on the same expression.

It would be nice if you could modify
"http://sqlite.org/draft/optoverview.html" to explicitly mention how
an index on an expression can be used.  If sqlite cannot yet use
indexes on expressions in any way, but only create and maintain them,
making them effectively useless until a future version of sqlite that
will be able to use them, then instead mention that fact in
"http://sqlite.org/draft/lang_createindex.html" .

Thanks,

Zsbán Ambrus
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Scott Hess
In reply to this post by Dominique Devienne
On Wed, Oct 7, 2015 at 9:05 AM, Dominique Devienne <[hidden email]>
wrote:

> On Wed, Oct 7, 2015 at 5:39 PM, Richard Hipp <[hidden email]> wrote:
> > On 10/7/15, Jaroslaw Staniek <[hidden email]> wrote:
> > > ​ would you elaborate what​ is the
> > > benefit of using x.y.z versioning scheme if so many new features come
> to
> > > the "z" release?
> >
> > [...] The community seems to want the second number (current 8) to
> > increment
> > every time a new feature is added to SQLite.  I will take your request
> > under advisement.  Realize, however, that had the current preferred
> > number scheme been used for SQLite from the beginning, the next
> > release would be called 3.112.
> >
>
> That 3.112 version is a better reflection of all the changes in a way.
>
> Minor version bumps are kinda arbitrary,


Having been involved in open source and commercial software for 25 years,
by now I've figured out that version numbers are themselves kinda
arbitrary.  I honestly don't think that the SQLite mailing list having this
tired old discussion is going to shed any new light on the issue or result
in a system which pleases everyone.  There is no chance that the version
number is going to become a standardized reliable form out out-of-band
messaging.  If you care about what's in there, you're going to have to pay
attention to what's in there.

-scott
_______________________________________________
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: SQLite version 3.8.12 enters testing

Richard Hipp-3
In reply to this post by Zsbán Ambrus
On 10/7/15, Zsbán Ambrus <[hidden email]> wrote:
>
> I have concerns with the [indexes on expressions] documentation.
>

New documentation covering indexes on expressions has been added.
Please let me know if you think more is needed.
--
D. Richard Hipp
[hidden email]
_______________________________________________
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: SQLite version 3.8.12 enters testing

Peter Aronson-3
I assume, like with similar enhancements, a database created at SQLite 3.8.12 with an expression index will be unreadable with earlier versions of SQLite?  As, for instance, a database created at 3.8.11 with an index with a where clauses causes SQLite 3.715.2 to fail when trying execute any SQL statements with "Error: malformed database schema (index name) - near "where": syntax error?

Peter


     On Wednesday, October 7, 2015 12:42 PM, Richard Hipp <[hidden email]> wrote:
   
 

 On 10/7/15, Zsbán Ambrus <[hidden email]> wrote:
>
> I have concerns with the [indexes on expressions] documentation.
>

New documentation covering indexes on expressions has been added.
Please let me know if you think more is needed.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


 
 
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Jaroslaw Staniek
In reply to this post by Richard Hipp-3
On 7 October 2015 at 17:39, Richard Hipp <[hidden email]> wrote:

> On 10/7/15, Jaroslaw Staniek <[hidden email]> wrote:
> > ​ would you elaborate what​ is the
> > benefit of using x.y.z versioning scheme if so many new features come to
> > the "z" release?
>
> That's the versioning scheme that has been used by SQLite for 15
> years.  Back when it was adopted, 15 years ago, it was certainly *not*
> the case that 99.9% of software did something different.  In fact, 15
> years ago, the current SQLite versioning scheme was rather common.
>
> The community seems to want the second number (current 8) to increment
> every time a new feature is added to SQLite.  I will take your request
> under advisement.  Realize, however, that had the current preferred
> number scheme been used for SQLite from the beginning, the next
> release would be called 3.112.
>
> ​
Thanks so much, such a linear version would be appreciated.

PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1
 -- I think versions x.y.z.v would be no longer needed.






--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
_______________________________________________
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: SQLite version 3.8.12 enters testing

Richard Hipp-3
In reply to this post by Peter Aronson-3
On 10/7/15, Peter Aronson <[hidden email]> wrote:
> I assume, like with similar enhancements, a database created at SQLite
> 3.8.12 with an expression index will be unreadable with earlier versions of
> SQLite?  As, for instance, a database created at 3.8.11 with an index with a
> where clauses causes SQLite 3.715.2 to fail when trying execute any SQL
> statements with "Error: malformed database schema (index name) - near
> "where": syntax error?

Correct.  On the other hand, a database created using 3.8.12 that does
NOT use new features, should be readable and writable by all prior
versions of SQLite.
--
D. Richard Hipp
[hidden email]
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

Scott Robison-2
In reply to this post by Jaroslaw Staniek
On Wed, Oct 7, 2015 at 2:06 PM, Jaroslaw Staniek <[hidden email]> wrote:

>
>
> On 7 October 2015 at 17:39, Richard Hipp <[hidden email]> wrote:
>
>> On 10/7/15, Jaroslaw Staniek <[hidden email]> wrote:
>> > ​ would you elaborate what​ is the
>> > benefit of using x.y.z versioning scheme if so many new features come to
>> > the "z" release?
>>
>> That's the versioning scheme that has been used by SQLite for 15
>> years.  Back when it was adopted, 15 years ago, it was certainly *not*
>> the case that 99.9% of software did something different.  In fact, 15
>> years ago, the current SQLite versioning scheme was rather common.
>>
>> The community seems to want the second number (current 8) to increment
>> every time a new feature is added to SQLite.  I will take your request
>> under advisement.  Realize, however, that had the current preferred
>> number scheme been used for SQLite from the beginning, the next
>> release would be called 3.112.
>>
>> ​
> Thanks so much, such a linear version would be appreciated.
>
> PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1
>  -- I think versions x.y.z.v would be no longer needed.
>

Really, the SQLite3 versioning isn't that far off from Semantic Versioning.
Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH.

Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading
through the release history it is fairly clear that a change in MAJOR
usually results from MAJOR new functionality, MINOR is for relatively MINOR
new functionality, and PATCH is apparently never used outside that context.

While I personally have no complaints with people who use Semantic
Versioning, I don't see SQLite versioning as being horribly incompatible
with it. In fact, if I were making the decision, I'd keep the current
versioning.

--
Scott Robison
_______________________________________________
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: [sqlite-dev] SQLite version 3.8.12 enters testing

jose isaias cabrera

"Scott Robison" wrote...


> On Wed, Oct 7, 2015 at 2:06 PM, Jaroslaw Staniek <[hidden email]> wrote:
>
>>
>>
>> On 7 October 2015 at 17:39, Richard Hipp <[hidden email]> wrote:
>>
>>> On 10/7/15, Jaroslaw Staniek <[hidden email]> wrote:
>>> > ​ would you elaborate what​ is the
>>> > benefit of using x.y.z versioning scheme if so many new features come
>>> > to
>>> > the "z" release?
>>>
>>> That's the versioning scheme that has been used by SQLite for 15
>>> years.  Back when it was adopted, 15 years ago, it was certainly *not*
>>> the case that 99.9% of software did something different.  In fact, 15
>>> years ago, the current SQLite versioning scheme was rather common.
>>>
>>> The community seems to want the second number (current 8) to increment
>>> every time a new feature is added to SQLite.  I will take your request
>>> under advisement.  Realize, however, that had the current preferred
>>> number scheme been used for SQLite from the beginning, the next
>>> release would be called 3.112.
>>>
>>>
>> Thanks so much, such a linear version would be appreciated.
>>
>> PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1
>>  -- I think versions x.y.z.v would be no longer needed.
>>
>
> Really, the SQLite3 versioning isn't that far off from Semantic
> Versioning.
> Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH.
>
> Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading
> through the release history it is fairly clear that a change in MAJOR
> usually results from MAJOR new functionality, MINOR is for relatively
> MINOR
> new functionality, and PATCH is apparently never used outside that
> context.
>
> While I personally have no complaints with people who use Semantic
> Versioning, I don't see SQLite versioning as being horribly incompatible
> with it. In fact, if I were making the decision, I'd keep the current
> versioning.

I agree.  Keep the same versioning schema.

jic

_______________________________________________
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: SQLite version 3.8.12 enters testing

Simon Slavin-3
In reply to this post by Richard Hipp-3

On 7 Oct 2015, at 8:42pm, Richard Hipp <[hidden email]> wrote:

> New documentation covering indexes on expressions has been added.
> Please let me know if you think more is needed.

I tentatively suggest that modifications be made to the text describing

<http://sqlite.org/draft/pragma.html#pragma_index_info>

and

<http://sqlite.org/draft/pragma.html#pragma_index_xinfo>

.  However it may be that such changes would just lengthen the explanation without adding anything useful, and that any programmer who tries out those PRAGMAs with the new indexes won't have any trouble understanding what they see.

It also might be useful to produce a -2 in the second output column for index_xinfo, for columns which are calculations.

I wonder what happens if an index is defined which uses an application-defined functions, and a later attempt is made to use the database without that function defined.  I can see an argument for returning an error when any relevant SELECT is attempted.  But I can also see an argument for returning an error only when an attempt is made to INSERT or UPDATE into the indexed table.

Simon.
_______________________________________________
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: SQLite version 3.8.12 enters testing

Peter Aronson-3
Currently if you have a check constraint with a user-defined function that is not defined in the current environment, you can not execute any SQL statements in that database -- you get the same error you get with features not supported in the current release.  I suspect the same thing would happen here.

Peter


     On Wednesday, October 7, 2015 1:27 PM, Simon Slavin <[hidden email]> wrote:
   
 

 
On 7 Oct 2015, at 8:42pm, Richard Hipp <[hidden email]> wrote:

> New documentation covering indexes on expressions has been added.
> Please let me know if you think more is needed.

I tentatively suggest that modifications be made to the text describing

<http://sqlite.org/draft/pragma.html#pragma_index_info>

and

<http://sqlite.org/draft/pragma.html#pragma_index_xinfo>

.  However it may be that such changes would just lengthen the explanation without adding anything useful, and that any programmer who tries out those PRAGMAs with the new indexes won't have any trouble understanding what they see.

It also might be useful to produce a -2 in the second output column for index_xinfo, for columns which are calculations.

I wonder what happens if an index is defined which uses an application-defined functions, and a later attempt is made to use the database without that function defined.  I can see an argument for returning an error when any relevant SELECT is attempted.  But I can also see an argument for returning an error only when an attempt is made to INSERT or UPDATE into the indexed table.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


 
 
_______________________________________________
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: SQLite version 3.8.12 enters testing

Darren Duncan
In reply to this post by Scott Robison-2
Semantic versioning in general doesn't have any specific format, it just means
that within a project the succession of version numbers conveys information by
itself.  There's no requirement there has to be 3 parts or whatever.  I consider
SQLite's versioning scheme to both be very appropriate and it is semantic
versioning, not just like such.

As a digression, for my own projects I like to use a semantic versioning scheme
of 4 parts like [major.branch.incompatible.compatible] that works like this
(assume generally each increment of a part means subsequent parts reset to zeros):

1. Incrementing 'major' means what it typically means, a substantial rewrite
that is free to be arbitrarily different and incompatible with the prior major.

2. The 'branch' is inspired by Perl's versioning scheme, in that it alternates
between even and odd numbers where even means production and odd means
development.  When one is making changes that are large enough that there should
be dev releases first, eg alpha/beta/etc, a development branch is created and
those releases are x.odd.y.z until they're considered production ready, then,
the development branch becomes a maintenance branch and releases become
x.even.y.z etc.  So example first production releases are 1.0.0.0 or 1.2.0.0 etc
while first dev/alpha/etc releases are 1.1.0.0 and 1.3.0.0 etc.  Each branch may
be but isn't necessarily incompatible with prior ones.

3. Incrementing 'incompatible' means that some change was made that is known to
break at least some use case, whatever the reason for it, and this was done
without having a separate branch / dev-prod status flip.  This includes security
fixes that disallow something previously allowed.

4. Incrementing 'compatible' means that the authors consider the change to not
break anything / be fully backwards-compatible, whether due to being a new
feature or a bug fix.

-- Darren Duncan

On 2015-10-07 1:13 PM, Scott Robison wrote:

> Really, the SQLite3 versioning isn't that far off from Semantic Versioning.
> Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH.
>
> Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading
> through the release history it is fairly clear that a change in MAJOR
> usually results from MAJOR new functionality, MINOR is for relatively MINOR
> new functionality, and PATCH is apparently never used outside that context.
>
> While I personally have no complaints with people who use Semantic
> Versioning, I don't see SQLite versioning as being horribly incompatible
> with it. In fact, if I were making the decision, I'd keep the current
> versioning.
>

_______________________________________________
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: SQLite version 3.8.12 enters testing

R Smith
In reply to this post by Peter Aronson-3

Some notes on 3.8.12: (Brilliant release btw, thanks)

I've been following the thread about the version numbering, and at first
thought the OP was a little over-enthusiastic about increasing version
numbers prematurely, but then after reading the release notes, I have to
agree to some extent - That is - I am not sure we should be changing the
way SQLite is versioned altogether, but maybe a bit more prolific in the
release versions? This definitely feels like a 3.9 release rather than a
3.8.12. I mean it introduces functionality that a 3.8.11 engine won't be
able to comprehend - and not just one obscure item either.

--------------------------------

The Indexed expressions document
(https://www.sqlite.org/draft/expridx.html) notes that the expression
must be exactly reproduced in the query to make use of it (i.e. exactly
as it was defined in the CREATE INDEX statement).
It goes on to note that "exactly" means syntactically equivalent (not
mathematically etc.), which is great, and that whitespace does not
matter. What about Capitalization and quotation?

i.e. - for this schema:

    i.e. - for this schema:
    CREATE TABLE t2(x,y,z);
    CREATE INDEX t2xy ON t2(x+y);

    Would these all be equivalent?

    SELECT * FROM t2 WHERE X+y=22;
    SELECT * FROM t2 WHERE "x" + "y" = 22;
    SELECT * FROM t2 WHERE "x" + Y = 22;


Whatever the answer, may it be added to the documentation please? (A
short example like the above would suffice I think).

-----------------------------

Documentation error in the Restrictions section (typo):
"2. Expressions in CREATE INDEX *statmeent* may contain function calls,
but only to functions whose output is always determined completely by
its..."

------------------------------

Documentation error in the Release notes (pluralization):
"Enhance the dbstat virtual table
<https://www.sqlite.org/draft/dbstat.html> so that it can be used as *a
table-valued functions
<https://www.sqlite.org/draft/vtab.html#tabfunc2>* where the argument is..."


Thanks,
Ryan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12