Plan to v2 and introduce Breaking Change

[shirou]

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 Breaking change: use state code rather than "description" #173)

... (add whenever we found something)

When v2 is introduced?

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

[shirou]

I have started migration to v2 on v2 branch.

[shirou]

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

[shirou]

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.

[miniwark]

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).

[shirou]

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.

[miniwark]

so I gave up. sigh.

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

[codeskyblue]

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

[Lomanic]

We are on v2 for a while now.