vgo suggested that package developers put the major version into the import path e.g. foo/v1. However dealing with a VCS like git, this thought occur to me, what would it look like when the project needs to move from v1 to v2?
In git we can rename the file in the entire history which messes things up for everyone so that's a bad thing to do. We can also copy paste v1 into the v2 folder, but then we lose the entire history of the files and would need to refer to the history of the other folder so this is a huge pain. We can also create a dummy repository that just submodules v1 and v2 to the actual source repository but this isn't pretty and feels kinda hackish. I also thought maybe do all development on v0 and then have v1/v2/etc... just be wrappers to v0. The last one makes the most sense to me, so I guess question is, is there a better way to handle multiple API version paths? Especially when there are many sub packages in the same repository. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
