Giters

shirou / gopsutil

psutil for golang

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Plan to v2 and introduce Breaking Change

shirou opened this issue · comments

commented

After replacing lsof (#164) , I have a plan to use semantic versioning and use gopkg.in. Current will be tagged the v1 at that time, and start v2 branch.

I will appreciate if you write some comments about this idea.

list of (possible) breaking changes

  • change JSON key from snake_case to camlCase.
  • [ ] change types from int32/64 and so on, to just int and uint.
  • golint acceptable
    • net.NetConnections -> net.Connections, disk.DiskPartitions -> disk.Partitions and so on
  • process.State() returns 'R' not 'running' in Linux (see #173)

... (add whenever we found something)

When v2 is introduced?

Target is end of March, 2016. But it may postponed.

commented

I have started migration to v2 on v2 branch.

commented

change types from int32/64 to int is deleted. I tried but I think it forces too many changes.

commented

I decided to not use gopkg.in. When I use github.com/shirou in source code, using gopkg.in becomes trouble due to the internal package. Change to recommend vendoring.

commented

Hi !

  • What about a Godeps file too ? This is used by gpm and may be useful as this library is a bit "low level" and therefore may be used by system monitoring tools (who generally need API stability and dependencies version management)
  • change types from int32/64 to int is deleted This would have been a good change... It would have been more easy to manage strings conversion for display by simply using always using strconv.Itoa() instead of strconv.FormatInt(i, 10) or strconv.FormatInt(int64(i), 10).
commented

Thank you for this comments.

Godeps or something

gopsutil itself depends only a few packages, for the Windows environment. I believe applications may use a vendoring, not library. And also, I always thinking about API stability. So if API is changed, I will introduce new major version like the v2. (BTW, Godeps is introduced by godep, I think)

change types from int32/64 to int is deleted This would have been a good change...

Yah, I was very worried about this. But when I tried, I had to change so many codes, so I gave up. sigh.

commented

so I gave up. sigh.

Don't give up! Code re-factoring is always a painful, but you will feel happy when done!

commented

So, when modify cpu.TimeStat type from float64 to uint64. Because float64 always loss precision

commented

We are on v2 for a while now.