0.20250818.0

0.20250818.0

0.20250807.0

0.20250807.0

0.20250701.0

0.20250701.0

0.20250514.0

0.20250514.0

0.20250415.0

BoringSSL usage typically follows a “live at head” model. Projects pin to whatever the current latest of BoringSSL is at the time of update, and regularly update it to pick up new changes.

Some systems cannot consume git revisions and expect git tags. BoringSSL tags periodic snapshots as “releases”, to meet the needs of those systems. These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest untagged revision when updating.

0.20250311.0

BoringSSL usage typically follows a “live at head” model. Projects pin to whatever the current latest of BoringSSL is at the time of update, and regularly update it to pick up new changes.

Some systems cannot consume git revisions and expect git tags. BoringSSL tags periodic snapshots as “releases”, to meet the needs of those systems. These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest untagged revision when updating.

0.20250212.0

BoringSSL usage typically follows a “live at head” model. Projects pin to whatever the current latest of BoringSSL is at the time of update, and regularly update it to pick up new changes.

Some systems cannot consume git revisions and expect git tags. BoringSSL tags periodic snapshots as “releases”, to meet the needs of those systems. These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest untagged revision when updating.

0.20250114.0

BoringSSL usage typically follows a “live at head” model. Projects pin to whatever the current latest of BoringSSL is at the time of update, and regularly update it to pick up new changes.

Some systems cannot consume git revisions and expect git tags. BoringSSL tags periodic snapshots as “releases”, to meet the needs of those systems. These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest untagged revision when updating.

0.20241209.0

BoringSSL usage typically follows a “live at head” model. Projects pin to whatever the current latest of BoringSSL is at the time of update, and regularly update it to pick up new changes.

Some systems cannot consume git revisions and expect git tags. BoringSSL tags periodic snapshots as “releases”, to meet the needs of those systems. These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest untagged revision when updating.

0.20241203.0

BoringSSL usage typically follows a “live at head” model. Projects pin to whatever the current latest of BoringSSL is at the time of update, and regularly update it to pick up new changes.

Some systems cannot consume git revisions and expect git tags. BoringSSL tags periodic snapshots as “releases”, to meet the needs of those systems. These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest untagged revision when updating.