Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Kind of a pain for us (http://mosh.mit.edu). We have some distro watchfiles that look at this location, and we'll have to get them to switch to whatever new location we move to.

(Ironically a few weeks ago GitHub made an unrelated change to their URL scheme that broke all the Debian watchfiles, including ours, that look for new tags.)

Some advance notice would probably have been helpful, instead of immediately killing this off. On the other hand, it's not like we're paying them to host our project.

Like most Unix software projects, we do want to prepare binary .tar.gzs of the Mosh releases, which have a ./configure and don't require autotools (unlike the repository, which is for maintainers and requires autotools to build). We wouldn't want to use a tag download of a .tgz as our authoritative release because there's no reason to think the sha256 will be stable.



Yeah I'm surprised to see them essentially drop support for this common workflow... downloading auto-tarballed tagged SCM commits is insufficient for Autotools projects, or other situations where you need to do pre-processing on your source code with (potentially fragile / version sensitive) tools which you don't want to require your end users to have installed.

It's not like inexpensive file hosting is difficult to come by these days, thankfully. And it's probably better for one's main distribution site to be on a domain under one's own control, anyway. But it was more convenient to be able to just put it up on GitHub, and somewhat more inspiring of confidence in the source archive's integrity.

I wonder how much this feature was costing them, anyway? And whether they'll lose out in any significant way when links to projects' canonical release archives point away from GitHub...




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: