[matthewbauer]

I think a tool like that could be very useful! The main issue with basing it off of Git commits is that there is no guarantee that the last commit with a given version is actually a good version. Consider the case where a-1.0 depends on b-1.0 and b is updated to b-2.0 in a commit so that a is not compatible with b-2.0. Even though a-1.0 is still around, it's not going to work until we update it to a-2.0, so you need some more complex constaint solving on top of your commits to figure out what works.

I would prefer doing it based on the 6-month release channels, so you get multiple version for every 6 months. You end up with some gaps between versions, but also have more guarantees everything actually works together. Basically "nix search" with multiple channels.

I actually had to do something similar with GHC versions for a project of mine. It turns out you can run Nixpkgs all the way back to the first release in 13.10 (LC_ALL=C is needed). Obviously not that long ago right now, but it should continue to work as time goes on & give us 10+ years.

https://gist.github.com/matthewbauer/ecdb665f84b7f6100f3f6e3...

[asymmetric]

Wouldn’t it be enough to checkout the commit where a-x.0 was updated, rather than the last known commit where a is at x.0? That way, if the packagr built successfully at that commit, you know it’s a good version.

We do something similar (and the way more manual) here[0].

[0]: https://github.com/dapphub/dapptools/blob/master/overlay.nix...

[matthewbauer]

That would work better. It probably still requires some curation. For instance CVE patches, configuration changes, and added platform support usually won’t include a version change. Just using the first commit may mean you miss those changes.

[matthewbauer]

I have a quick mockup of something like this in Nix:

https://gist.github.com/matthewbauer/7c57f8fb69705bb8da9741b...

It keeps makes past versions of packages available to you, but does not really help with discoverability.