The go tool works with other VCSes, such as mercurial, bitbucket and subversion.
On Fri, Jul 29, 2016 at 6:47 PM Chad <send2b...@gmail.com> wrote: > > 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. > -- 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.
