On Saturday, July 30, 2016 at 1:43:36 AM UTC+2, Dave Cheney wrote: > > How about a tag? which developers should be doing as part of any mature > release process.
Sure, a tag may be possible. I thought timestamp because it is easily generated by a machine as well as parsable, with a well defined semantic and ever-increasing. Anything that share these features would do I guess. On Saturday, July 30, 2016 at 1:44:10 AM UTC+2, Gregory Golberg wrote: > > What is wrong with using git submodules inside the vendor directory, > submodules pointing to the tag/revision of your choice? > > I think it's the fact that it locks people into a single version control system. The tooling should ideally remain agnostic for forward-compatibility. > On Friday, July 29, 2016 at 10:24:20 AM UTC-7, Chad wrote: >> >> To be more precise, I am not thinking about a package manager but rather >> more of a kind of package registration interface. A bit like godoc. But >> working by submissions of vcs hosts links (thus allowing mirror links). >> >> Backward compatibility requirements are making things simple already: the >> latest "revision" should have the priority. >> >> On Friday, July 29, 2016 at 6:33:28 PM UTC+2, Chad wrote: >>> >>> Oh I see now. I guess we need something inbetween go get and the >>> different vcs to register and timestamp a package each time it is declared >>> as having been updated. (would still be vcs agnostic though, it's just to >>> timestamp the package files) >>> >>> Would make releasing a package a bit more of a manual process but it >>> could be a good thing. >>> >>> The tooling should be able then to decide up on the latest vendored >>> package to use. >>> >>> That would also decouple the import paths from "github" as is currently >>> often the case. >>> >>> On Friday, July 29, 2016 at 2:47:20 AM UTC+2, Dave Cheney wrote: >>>> >>>> Yes, to use the vendor/ feature project authors need to flatten all >>>> their dependencies into a single, top level, vendor/ folder. This is >>>> currently difficult as there is no common way to look at two copies of the >>>> same source code and decode if there are the same, and if not, which >>>> should >>>> take priority. >>> >>> -- 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.
