Re: [go-nuts] go modules and vendor: redundant features?
On Sat, Nov 17, 2018 at 6:15 PM Justin Israel wrote: > > > On Sat, Nov 17, 2018 at 6:06 PM Robert Engels > wrote: > >> I think that is incorrect. The vendoring was a way to ensure certain >> dependencies remained constant. The modules should eliminate that, barring >> deletion of the source repo. >> > > Even with modules, vendoring is still useful for situations where external > network access is limited and the internal network does not yet have an > Athena proxy to serve dependencies. Also, before modules keeping > dependencies constant was achievable with glide, godeps, dep, etc, > regarless of whether you choose to vendor it or not. But yes, vendoring > made it so that your build would prefer that location over your GOPATH, and > the module system provides a versioned cache now. I still like the idea of > being able to vendor if that makes the most sense. > s/Athena/Athens/ > >> >> On Nov 16, 2018, at 11:00 PM, Justin Israel >> wrote: >> >> >> >> On Sat, Nov 17, 2018 at 5:34 PM Henry wrote: >> >>> Hi, >>> >>> It seems to me that go modules and vendor attempt to solve the same >>> problem. I wonder whether we should just choose one and scrap the other, or >>> find a way to consolidate them under a single unified feature. >>> >> >> Comparing "modules" and "vendoring" have only the most minor overlap. The >> module system is a built-in way to describe and track dependencies. This >> ultimately bakes down into a go.sum 'lock' file describing exactly what you >> are using at a moment in time. The lock file can then be consulted in the >> future to download those exact dependencies and reproduce the same build as >> when it was originally written. Vendoring is a way to store dependency code >> within the repo to avoid relying on downloading it again. It may or may not >> store any information about the versions and it may or may not have been >> done manually. The vendoring feature in the go module command is just a way >> to store the dependencies from the go.sum solution within the repo and >> avoid the download step. >> >> Why do you feel they are mutually exclusive? What if someone wants the >> dependency management of modules and being able to avoid GOPATH, while also >> wanting to avoid relying on a download process? >> >> >>> I am a bit concerned with the direction Go is going. People keep adding >>> stuffs into Go and later find themselves unable to remove existing features >>> due to the backward compatibility promise. Go 1.11 is a different beast >>> than Go 1.0, and is significantly more complex. >>> >>> I think Go2 is an opportunity to learn from Go1, and to start from a >>> clean slate by scraping and consolidating features. Go2 needs to be simpler >>> than Go1.11 >>> >>> Henry >>> >>> -- >>> 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. >> >> -- 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.
Re: [go-nuts] go modules and vendor: redundant features?
On Sat, Nov 17, 2018 at 6:06 PM Robert Engels wrote: > I think that is incorrect. The vendoring was a way to ensure certain > dependencies remained constant. The modules should eliminate that, barring > deletion of the source repo. > Even with modules, vendoring is still useful for situations where external network access is limited and the internal network does not yet have an Athena proxy to serve dependencies. Also, before modules keeping dependencies constant was achievable with glide, godeps, dep, etc, regarless of whether you choose to vendor it or not. But yes, vendoring made it so that your build would prefer that location over your GOPATH, and the module system provides a versioned cache now. I still like the idea of being able to vendor if that makes the most sense. > > On Nov 16, 2018, at 11:00 PM, Justin Israel > wrote: > > > > On Sat, Nov 17, 2018 at 5:34 PM Henry wrote: > >> Hi, >> >> It seems to me that go modules and vendor attempt to solve the same >> problem. I wonder whether we should just choose one and scrap the other, or >> find a way to consolidate them under a single unified feature. >> > > Comparing "modules" and "vendoring" have only the most minor overlap. The > module system is a built-in way to describe and track dependencies. This > ultimately bakes down into a go.sum 'lock' file describing exactly what you > are using at a moment in time. The lock file can then be consulted in the > future to download those exact dependencies and reproduce the same build as > when it was originally written. Vendoring is a way to store dependency code > within the repo to avoid relying on downloading it again. It may or may not > store any information about the versions and it may or may not have been > done manually. The vendoring feature in the go module command is just a way > to store the dependencies from the go.sum solution within the repo and > avoid the download step. > > Why do you feel they are mutually exclusive? What if someone wants the > dependency management of modules and being able to avoid GOPATH, while also > wanting to avoid relying on a download process? > > >> I am a bit concerned with the direction Go is going. People keep adding >> stuffs into Go and later find themselves unable to remove existing features >> due to the backward compatibility promise. Go 1.11 is a different beast >> than Go 1.0, and is significantly more complex. >> >> I think Go2 is an opportunity to learn from Go1, and to start from a >> clean slate by scraping and consolidating features. Go2 needs to be simpler >> than Go1.11 >> >> Henry >> >> -- >> 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. > > -- 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.
Re: [go-nuts] go modules and vendor: redundant features?
I think that is incorrect. The vendoring was a way to ensure certain dependencies remained constant. The modules should eliminate that, barring deletion of the source repo. > On Nov 16, 2018, at 11:00 PM, Justin Israel wrote: > > > >> On Sat, Nov 17, 2018 at 5:34 PM Henry wrote: >> Hi, >> >> It seems to me that go modules and vendor attempt to solve the same problem. >> I wonder whether we should just choose one and scrap the other, or find a >> way to consolidate them under a single unified feature. > > Comparing "modules" and "vendoring" have only the most minor overlap. The > module system is a built-in way to describe and track dependencies. This > ultimately bakes down into a go.sum 'lock' file describing exactly what you > are using at a moment in time. The lock file can then be consulted in the > future to download those exact dependencies and reproduce the same build as > when it was originally written. Vendoring is a way to store dependency code > within the repo to avoid relying on downloading it again. It may or may not > store any information about the versions and it may or may not have been done > manually. The vendoring feature in the go module command is just a way to > store the dependencies from the go.sum solution within the repo and avoid the > download step. > > Why do you feel they are mutually exclusive? What if someone wants the > dependency management of modules and being able to avoid GOPATH, while also > wanting to avoid relying on a download process? > >> I am a bit concerned with the direction Go is going. People keep adding >> stuffs into Go and later find themselves unable to remove existing features >> due to the backward compatibility promise. Go 1.11 is a different beast than >> Go 1.0, and is significantly more complex. >> >> I think Go2 is an opportunity to learn from Go1, and to start from a clean >> slate by scraping and consolidating features. Go2 needs to be simpler than >> Go1.11 >> >> Henry >> -- >> 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. -- 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.
Re: [go-nuts] go modules and vendor: redundant features?
On Sat, Nov 17, 2018 at 5:34 PM Henry wrote: > Hi, > > It seems to me that go modules and vendor attempt to solve the same > problem. I wonder whether we should just choose one and scrap the other, or > find a way to consolidate them under a single unified feature. > Comparing "modules" and "vendoring" have only the most minor overlap. The module system is a built-in way to describe and track dependencies. This ultimately bakes down into a go.sum 'lock' file describing exactly what you are using at a moment in time. The lock file can then be consulted in the future to download those exact dependencies and reproduce the same build as when it was originally written. Vendoring is a way to store dependency code within the repo to avoid relying on downloading it again. It may or may not store any information about the versions and it may or may not have been done manually. The vendoring feature in the go module command is just a way to store the dependencies from the go.sum solution within the repo and avoid the download step. Why do you feel they are mutually exclusive? What if someone wants the dependency management of modules and being able to avoid GOPATH, while also wanting to avoid relying on a download process? > I am a bit concerned with the direction Go is going. People keep adding > stuffs into Go and later find themselves unable to remove existing features > due to the backward compatibility promise. Go 1.11 is a different beast > than Go 1.0, and is significantly more complex. > > I think Go2 is an opportunity to learn from Go1, and to start from a clean > slate by scraping and consolidating features. Go2 needs to be simpler than > Go1.11 > > Henry > > -- > 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.
[go-nuts] go modules and vendor: redundant features?
Hi, It seems to me that go modules and vendor attempt to solve the same problem. I wonder whether we should just choose one and scrap the other, or find a way to consolidate them under a single unified feature. I am a bit concerned with the direction Go is going. People keep adding stuffs into Go and later find themselves unable to remove existing features due to the backward compatibility promise. Go 1.11 is a different beast than Go 1.0, and is significantly more complex. I think Go2 is an opportunity to learn from Go1, and to start from a clean slate by scraping and consolidating features. Go2 needs to be simpler than Go1.11 Henry -- 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.
[go-nuts] HTTP client CheckRedirect behavior for the first redirect
It seems like http.Client's CheckRedirect hook only populates the via[n].Response for n>0 (i.e., not for the first hop). This is useful if, for instance, you want to check the status code (301, 302, etc) of each redirect. Here's a playground demo: https://play.golang.org/p/cKoWVhdjKwf I can file an issue, but I feel like I'm missing something, because this is the most obvious thing to want to do with CheckRedirect and nobody else seems to have complained about it. Can someone clue me in? Caleb -- 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.
Re: [go-nuts] Unable to view go-review.googlesource.com on Firefox 60.x
On Fri, 16 Nov 2018, at 6:05 PM, Wagner Riffel wrote: > I'm either on 60.3 under linux and it's working fine. OK thanks, it must be something on my system -- 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.
Re: [go-nuts] Memory limits
The 512GB heap limit was removed in go 1.11. Here's the commit that did it, it has some additional information: https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c -- 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.
Re: [go-nuts] Memory limits
This article https://syslog.ravelin.com/further-dangers-of-large-heaps-in-go-7a267b57d487 would imply it is far less than that. I responded that something didn’t feel right, but maybe Gos lack of generational GC is a real stumbling block here. > On Nov 16, 2018, at 11:58 AM, Matthew Zimmerman wrote: > > What are the current memory limits? I know it used to be 512gb. Is there a > difference between the platforms? I couldn't find documentation on this. > > Thanks! > -- > 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.
Re: [go-nuts] Unable to view go-review.googlesource.com on Firefox 60.x
I'm either on 60.3 under linux and it's working fine. On Fri, Nov 16, 2018 at 1:25 PM Sam Whited wrote: > > FWIW, I'm on 65 nightly and haven't noticed any problems (including back when > 63 was the nightly release). > > —Sam > > On Fri, Nov 16, 2018, at 09:22, Ian Davis wrote: > > Hi all, > > > > Since upgrading to Firefox 60.3 on Linux I am unable to view any pages > > on https://go-review.googlesource.com/ and I wondered if anyone else was > > seeing this problem or if it's an issue with my setup? > > > > Chromium renders the pages fine. When I view source with Firefox I see > > the following: which might be a clue to someone. > > > > Ian > > > > -- > > 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. > > > -- > Sam Whited > s...@samwhited.com > > -- > 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.
[go-nuts] Memory limits
What are the current memory limits? I know it used to be 512gb. Is there a difference between the platforms? I couldn't find documentation on this. Thanks! -- 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.
Re: [go-nuts] Unable to view go-review.googlesource.com on Firefox 60.x
FWIW, I'm on 65 nightly and haven't noticed any problems (including back when 63 was the nightly release). —Sam On Fri, Nov 16, 2018, at 09:22, Ian Davis wrote: > Hi all, > > Since upgrading to Firefox 60.3 on Linux I am unable to view any pages > on https://go-review.googlesource.com/ and I wondered if anyone else was > seeing this problem or if it's an issue with my setup? > > Chromium renders the pages fine. When I view source with Firefox I see > the following: which might be a clue to someone. > > Ian > > -- > 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. -- Sam Whited s...@samwhited.com -- 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.
[go-nuts] Unable to view go-review.googlesource.com on Firefox 60.x
Hi all, Since upgrading to Firefox 60.3 on Linux I am unable to view any pages on https://go-review.googlesource.com/ and I wondered if anyone else was seeing this problem or if it's an issue with my setup? Chromium renders the pages fine. When I view source with Firefox I see the following: which might be a clue to someone. Ian -- 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.
Re: [go-nuts] Re: blocking profile
Just remember that changing from unbuffered to buffered to make something work may just be hiding the problem and it will surface again in other situations. > On Nov 16, 2018, at 8:33 AM, sivasothy shanmugalingam wrote: > > Thanks, I used one channel that is blocking. I found error and correct it > >> On Fri, Nov 16, 2018 at 3:31 PM Vladimir Varankin wrote: >> I believe, "runtime.chanrecv1" is the receiving part of a channel. From what >> you've described, it sounds like you have a dead-lock somewhere. >> >> In your "out.svg" diagram check what functions are dominating around channel >> read and check if dead-lock is there. >> >> >>> On Thursday, November 15, 2018 at 6:09:15 PM UTC+1, soth...@gmail.com wrote: >>> Hello, >>> >>> I'm using four channles, and some TCP connections. >>> It works and one point my server does not get the data over tcp >>> connections.rr >>> Still No fatal error or panic error >>> >>> I tried here and there. Finally I did blocking profile. I show some data. >>> >>> I run >>> $go tool pprof -svg main blockprofile.prof > out.svg >>> >>> It shows 99.4% it is waiting for runtime.chanrecv1. >>> >>> I dont know how to interpret those result? What I have to do for detecting >>> the casue for above problem? >>> >>> Best regards >>> Sothy >>> >>> >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/WqGOTAH-7QA/unsubscribe. >> To unsubscribe from this group and all its topics, 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. -- 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.
Re: [go-nuts] Re: blocking profile
Thanks, I used one channel that is blocking. I found error and correct it On Fri, Nov 16, 2018 at 3:31 PM Vladimir Varankin wrote: > I believe, "runtime.chanrecv1" is the receiving part of a channel. From > what you've described, it sounds like you have a dead-lock somewhere. > > In your "out.svg" diagram check what functions are dominating around > channel read and check if dead-lock is there. > > > On Thursday, November 15, 2018 at 6:09:15 PM UTC+1, soth...@gmail.com > wrote: >> >> Hello, >> >> I'm using four channles, and some TCP connections. >> It works and one point my server does not get the data over tcp >> connections.rr >> Still No fatal error or panic error >> >> I tried here and there. Finally I did blocking profile. I show some data. >> >> I run >> $go tool pprof -svg main blockprofile.prof > out.svg >> >> It shows 99.4% it is waiting for runtime.chanrecv1. >> >> I dont know how to interpret those result? What I have to do for >> detecting the casue for above problem? >> >> Best regards >> Sothy >> >> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/WqGOTAH-7QA/unsubscribe. > To unsubscribe from this group and all its topics, 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.
[go-nuts] Re: blocking profile
I believe, "runtime.chanrecv1" is the receiving part of a channel. From what you've described, it sounds like you have a dead-lock somewhere. In your "out.svg" diagram check what functions are dominating around channel read and check if dead-lock is there. On Thursday, November 15, 2018 at 6:09:15 PM UTC+1, soth...@gmail.com wrote: > > Hello, > > I'm using four channles, and some TCP connections. > It works and one point my server does not get the data over tcp > connections.rr > Still No fatal error or panic error > > I tried here and there. Finally I did blocking profile. I show some data. > > I run > $go tool pprof -svg main blockprofile.prof > out.svg > > It shows 99.4% it is waiting for runtime.chanrecv1. > > I dont know how to interpret those result? What I have to do for > detecting the casue for above problem? > > Best regards > Sothy > > > > -- 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.
Re: [go-nuts] I cannot access global var from package. Any idea?
On Fri, Nov 16, 2018 at 2:40 PM Juan Mamani wrote: > Why can not access global var MyGlobalVar? Any idea? Go has no global scope. It has universe scope, but you cannot define anything there. `MyGlobalVar` has package scope. To access an exported identifier imported from pacakge foo, you must use the package qualifier, like in `foo.MyGlobalVar` - in the first approximation. For other options lookup "dot imports" but that's seldom a good choice. > According Golang docs should be possible. No. > It works when both files are in the same directory. Yes, package scope contains all TLD declarations in a package. visible everywhere in the package. > But when db.go is in another doesn't work. WAI -- -j -- 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.
[go-nuts] I cannot access global var from package. Any idea?
The sample code:
// main.go in varglobal/
package main
import(
"fmt"
"varglobal/db"
)
var MyGlobalVar string ="Any value :)"
func main(){
db.TryDisplayMyVar()
}
// db.go in varglobal/db/
package db
import "fmt"
func TryDisplayMyVar(){
fmt.Println("Value:",MyGlobalVar)
}
Results of compilation:
# varglobal/db
db/db.go:15:23: undefined: MyGlobalVar
Why can not access global var MyGlobalVar? Any idea?
According Golang docs should be possible. It works when both files are
in the same directory. But when db.go is in another doesn't work.
I tried this sample because I need to update big bunch of code
implementing one global variable from packages. Some good samaritan out
there?
--
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.
Re: [go-nuts] Joke in the air :D
Jajajajjjajajajaj let me commit a big LOL!! El vie., 16 nov. 2018 a las 0:29, Chris FractalBach () escribió: > It reached it's "golden years" > > -- > 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.
Re: [go-nuts] New Modules and git clones
On Thu, 2018-11-15 at 14:20 +, Paul Jolly wrote: […] > > The update rewrites non-canonical version identifiers to semver form, > > so A's v1 becomes v1.0.0 and E's dev becomes the pseudo-version for the > > latest commit on the dev branch, perhaps v0.0.0-20180523231146- > > b3f5c0f6e5f1. It is clearly there, I missed it. Perhaps the moral of the episode is that it might be good to make it a bit more "in your face" so as to avoid others missing the information in the future? Perhaps something as simple as a comment: E dev # Or whatever your branch is called on the example? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk -- 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. signature.asc Description: This is a digitally signed message part
