1339110 - Update sqlite to 3.17.0

Status: RESOLVED INACTIVE

(Core :: SQLite and Embedded Database Bindings, defect, P5)

Description

[Tom Ritter [:tjr]]

This is a (semi-)automated bug making you aware that there is an available upgrade for an embedded third-party library.

sqlite is currently at version 3.16.2 in mozilla-central, and the latest version of the library released is 3.17.0.

I fetched the latest version of the library from https://www.sqlite.org/chronology.html.

You can leave this bug open, and it will be updated if a newer version of the library becomes available. If you close it as WONTFIX, please indicate if you do not wish to receive any future bugs upon new releases of the library.

Comment 1

[Marco Bonardo [:mak]]

Hm, we currently have people tracking Sqlite versions, but it may be useful for future reference, so leaving this open. Though the work will continue happening on separate bugs, like bug 1339321.

Comment 3

[Marco Bonardo [:mak]]

I think the idea is that this bug keeps changing its title and adds comments every time a new Sqlite version is released. That makes it sort of pointless until we do it manually, but could still be handy.

If we dupe it, it will be like wontfixing it, that is we won't get notifications.

Now I can't access the blocked bug, but it sounds like an ok idea to be notified.

Comment 4

[Marco Bonardo [:mak]]

fwiw, I think it would be better if the script would file a separate bug every time, or would be more generic.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

I guess if we want to automate the filing of these bugs in the future, that can work. I don't think this particular bug serves much purpose since we already have a 3.17.0 tracking bug anyway. I would certainly like to be CCed to future auto-filed bugs if that's the route we want to go, though.

Comment 6

[Tom Ritter [:tjr]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #5)
> I guess if we want to automate the filing of these bugs in the future, that
> can work. I don't think this particular bug serves much purpose since we
> already have a 3.17.0 tracking bug anyway. I would certainly like to be CCed
> to future auto-filed bugs if that's the route we want to go, though.

I will cc you on version bump bugs.

My current plan has been to file a new bug for a library bump if the old one was fixed and closed; and update the text of the current bug if it had not been resolved by the time of the new library. If a library had a particular bug for version bumps I would block that (like 1210886)

And, if desired, I would just not open bugs for any particular library if it was requested.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

We generally do a good job staying on top of SQLite releases (you can see from the history of the bugs that they're almost always filed within a day of a new release coming out), but I certainly am not opposed to an auto-filer doing it. Is there any way you can set it to depend on the previous update bug automatically too?

Comment 8

[Tom Ritter [:tjr]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #7)
> We generally do a good job staying on top of SQLite releases (you can see
> from the history of the bugs that they're almost always filed within a day
> of a new release coming out), but I certainly am not opposed to an
> auto-filer doing it. Is there any way you can set it to depend on the
> previous update bug automatically too?

Yea I should be able to do that =)

Comment 9

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.