Update sqlite to 3.17.0

RESOLVED INACTIVE

Status

()

P5
normal
RESOLVED INACTIVE
2 years ago
6 months ago

People

(Reporter: tjr, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.
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.
Priority: -- → P5
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1339321
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
fwiw, I think it would be better if the script would file a separate bug every time, or would be more generic.
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.
(Reporter)

Comment 6

2 years ago
(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.
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?
(Reporter)

Comment 8

2 years ago
(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 =)
(Reporter)

Updated

2 years ago
No longer blocks: 1325608

Comment 9

6 months ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago6 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.