An implementation of libyear.com for go modules

Go to file

renovate e990abd763 Update dependency go to v1.23.4		2024-12-03 19:03:18 +00:00
pkg	add documentation	2021-05-09 17:25:23 -04:00
.gitignore	init	2021-04-09 22:01:41 -04:00
go.mod	Update dependency go to v1.23.4	2024-12-03 19:03:18 +00:00
go.sum	Update module golang.org/x/mod to v0.22.0	2024-11-07 22:02:42 +00:00
LICENSE	add BSD-3 license	2021-04-10 22:25:51 -04:00
main.go	correct mod name	2021-04-10 22:22:06 -04:00
readme.md	document default -h flag	2021-04-10 22:18:27 -04:00
renovate.json	Add renovate.json	2023-04-07 00:01:18 +00:00

readme.md

libyear

A simple measure of software dependency freshness. It is a single number telling you how up-to-date your dependencies are.

libyear.com

Usage

libyear only supports projects using go modules. It ignores dependencies that are replaced in a go.mod file.

-h: usage help text

-q: quiet mode; reduce logging and output only dependencies that are not at their latest version

-v: verbose mode; output diagnostic information

-indirect: include dependencies marked // indirect in go.mod in the calculation (excluded by default)

Example output

When run in a directory that contains a go.mod file:

$ libyear
github.com/pkg/errors: 1.03 year(s) (current: v0.8.1, newest: v0.9.1)
github.com/stretchr/testify: 1.51 year(s) (current: v1.4.0, newest: v1.7.0)
go.uber.org/atomic: 0.00 year(s) (up to date: v1.7.0)
go.uber.org/multierr: 0.00 year(s) (up to date: v1.6.0)
gopkg.in/yaml.v2: 2.01 year(s) (current: v2.2.2, newest: v2.4.0)
total libyear count: 4.55 year(s)

References

J. Cox, E. Bouwers, M. van Eekelen and J. Visser, Measuring Dependency Freshness in Software Systems. In Proceedings of the 37th International Conference on Software Engineering (ICSE 2015), May 2015 https://ericbouwers.github.io/papers/icse15.pdf