You both make good point to why that might have it's issues.
Taken into account the time mentioned it makes more sense to keep it
separate and have it's own release cycle.
Thanks for your input.
On Tue, Nov 7, 2017 at 1:46 PM Dave Cheney wrote:
>
>
> On Tuesday, 7 November 2017 22:29:29 UTC+11,
On Tuesday, 7 November 2017 22:29:29 UTC+11, Sotirios Mantziaris wrote:
>
> Apart from the time it would take to make changes to a tool in the
> toolchain i could come up with a reason for that:
>
> If a new feature gets added to go that would affect the debugger it would
> be tackled away as p
Apart from the time it would take to make changes to a tool in the
toolchain i could come up with a reason for that:
If a new feature gets added to go that would affect the debugger it would
be tackled away as part of the release as opposed to wait for the final
release and start implementing the
That statement is pretty aspirational. I think it is likely that the go tool
could grow the ability to understand repository tags, but beyond that I
wouldn’t bet on one specific tool.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscr
For that tool, which is not the subject of this thread, the maintainers are
willing to pay the price of inclusion in the toolchain.
As I stated in my original reply,I would hope we don't have to pay the same
price for the debugger.
I don't understand why anyone thinks that inclusion in the toolch
https://github.com/golang/dep/wiki/Roadmap
The goal with dep is to be absorbed into the go toolchain. That's the path
we're on, but it's up to the Go community - you! - to help us see it
through.
On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan wrote:
> dep is not part of the toolchain.
>
> On Tue,
dep is not part of the toolchain.
On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris,
wrote:
> would it not make sense them to keep dep out of the std toolchain to adapt
> faster to changes?
>
> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote:
>>
>> If you reported an issue today,
would it not make sense them to keep dep out of the std toolchain to adapt
faster to changes?
On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote:
>
> If you reported an issue today, Nov 6, you could be waiting nearly 9
> months to see a fix in the next released version of Go.
>
If you reported an issue today, Nov 6, you could be waiting nearly 9 months
to see a fix in the next released version of Go.
A project living outside the standard library has little going against it
other than you have to compile it yourself.
On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirio
I do not know if the times you mentioned are indeed that long.
If it is true then you actually have a good argument.
On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>
> I hope not. Anything that ends up in the toolchain is slow to change and
> adapt to user needs. If I have
I hope not. Anything that ends up in the toolchain is slow to change and
adapt to user needs. If I have a problem with delve today, I can post an
issue, fix it and get the next version of delve az quick as a few hours. If
it would be in the toolchain it could take up to six months to get it
release
Yes i know that, but i wonder if it is time to fully integrate delve in the
go toolchain and ship it with every release like dep, which exists in
another repository, but will be fullly integrated into the toolchain and
the releases in some future version.
On Tuesday, November 7, 2017 at 1:38:27
12 matches
Mail list logo
