undefined

points

[-]

You're now arguing that it's easy, which is a completely different argument. The comment I responded to argued that it's unnecessary ("just do the rewrite in go.mod, leave source files unchanged").

For my thoughts about why it's not easy, see this comment: https://news.ycombinator.com/item?id=49870363

by cyberpunk1 hours ago|

parent|

[-]

Yep that sounds pretty bad. Personally, we'd just eat not being able to build old versions, we archive previous builds, and in the case of a hotfix or whatever we'd use the go.mod rewrite trick. Not sure why you needed the commit/branch setup, did you change the history?

by mort961 hours ago|

parent|

[-]

Have libfoo with a bunch of different versions. Authservice depends on libfoo 1.2.0. APIservice depends on libfoo 1.3.0.

Now you want to move from github.com to git.example.org. You change libfoo, authservice and apiservice to use git.example.org, that part is just simple tedious work. But the v1.2.0 and v1.3.0 tags of libfoo are old commits from before the move, so they still reference github.com! Now you need to branch off of the v1.2.0 and v1.3.0 tags of libfoo and do the same change there.

So we have only 3 repositories with only 2 dependencies and we already have to do the search/replace 5 times.

Imagine now that apiservice depends on authservice v2.3.7 just to include some type definitions. Authservice is currently on version 2.4.0 but the types haven't changed so apiservice hasn't upgraded its dependency. Now you need to branch off of authservice v2.3.7 too and do the job there. Oh and authservice v2.3.7 depends on libfoo v1.2.5, so now you need to make a branch off of libfoo v1.2.5 with the search/replace.

3 repositories with a straightforward dependency relationship, 7 search/replace jobs.

The numbers get terrifying as you scale this up.