add security clause

blas-STABILITY.md

API Stability Policy

We will not change the gonum/blas/... packages' exported API in backward incompatible ways. Future changes to these packages will not break dependent code.

Scope

This document is similar to and inspired by the Go 1 compatibility promise via Go kit RFC007.

Coverage

The promise of stability includes:

• The package name,
• Exported type declarations and struct fields (names and types),
• Exported function and method names, parameters, and return values,
• Exported constant names and values,
• Exported variable names and values,
• The documented behavior of all exported code.

Exceptions

• Security. A security issue in the package may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.

• Unspecified behavior. Programs that depend on unspecified behavior may break in future releases.

• Bugs. If the package has a bug, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.

• Dot import of the blas/native package. If a program imports gonum/blas/native using import . "github.com/gonum/blas/native", additional names later defined in gonum/blas/native may conflict with other names defined in the program.

lapack-STABILITY.md

API Stability Policy

We will not change the gonum/lapack/... packages' exported API in backward incompatible ways. Future changes to these package will not break dependent code.

Scope

This document is similar to and inspired by the Go 1 compatibility promise via Go kit RFC007.

Coverage

The promise of stability includes:

• The package name,
• Exported type declarations and struct fields (names and types),
• Exported function and method names, parameters, and return values,
• Exported constant names and values,
• Exported variable names and values,
• The documented behavior of all exported code.

Exceptions

• Security. A security issue in the package may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.

• Unspecified behavior. Programs that depend on unspecified behavior may break in future releases.

• Bugs. If the package has a bug, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.

• Method sets in github.com/gonum/lapack. The method sets of lapack.Float64 and lapack.Complex128 may be extended.

• Dot import of the lapack/native package. If a program imports gonum/lapack/native using import . "github.com/gonum/lapack/native", additional names later defined in gonum/lapack/native may conflict with other names defined in the program.

• Methods marked internal in "github.com/gonum/lapack/native" are not covered by this API stability promise. Methods that are not excluded are defined in the lapack.Float64 and lapack.Complex128 interface method sets.

• The package "github.com/gonum/lapack/cgo/clapack". This package has the same promise of stability as the "syscall" package in the standard library.

matrix-STABILITY.md

API Stability Policy

We will not change the gonum/matrix/... packages' exported API in backward incompatible ways. Future changes to these packages will not break dependent code.

Scope

This document is similar to and inspired by the Go 1 compatibility promise via Go kit RFC007.

Coverage

The promise of stability includes:

• The package name,
• Exported type declarations and struct fields (names and types),
• Exported function and method names, parameters, and return values,
• Exported constant names and values,
• Exported variable names and values,
• The documented behavior of all exported code.

Exceptions

• Security. A security issue in the package may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.

• Unspecified behavior. Programs that depend on unspecified behavior may break in future releases.

• Bugs. If the package has a bug, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.

• Struct literals. For the addition of features it may be necessary to add fields to exported structs in the package API. Code that uses unkeyed struct literals (such as pkg.T{3, "x"}) to create values of these types would fail to compile after such a change. However, code that uses keyed literals (pkg.T{A: 3, B: "x"}) will continue to compile after such a change. We will update such data structures in a way that allows keyed struct literals to remain compatible, although unkeyed literals may fail to compile. (There are also more intricate cases involving nested data structures or interfaces, but they have the same resolution.) We therefore recommend that composite literals whose type is defined in a separate package should use the keyed notation.

• Dot imports. If a program imports a package using import . "path", additional names later defined in the imported package may conflict with other names defined in the program.