v4 release plan

[shirou]

(moved from #1547)

After several years of releasing v3, its about time for me to release v4. I am now thinking of adding the following two features

1. to be able to have platform specific information
   2. add optimization arguments to some function calls. -> already shipped in v3.

In addition, I would like to revisit and take in v4 labeled issues and PRs.

I want to discuss about v4 at here.

1. platform specific information

gopsutil is intended to be a platform independent library. However, there are always issues and PRs that request the inclusion of information that exists only on certain platforms. We would like to respond to this as follows.

For example, the following struct is currently defined. This definition is defined in the common file host.go.

type TemperatureStat struct {
	SensorKey string `json: "sensorKey"`
	Temperature float64 `json: "temperature"`
	High float64 `json: "sensorHigh"`
	Critical float64 `json: "sensorCritical"`
}

For all such structures, add a Specific() function in each individual platform file, such as host_linux.go

It might look like this.

type TemperatureStatLinux struct {
	Min float64
	Max float64
	Crit float64
	Alerm float64
}

func (s Foo) Specific() (TemperatureStatLinux, error) {
	return TemperatureStatLinux{Min: 100}, nil
}

To use platform specific information, you have to write something like s, err := tempreture.Specific(). This is a bit tedious, but the intention is to make it clear that this part is platform-dependent.

I am sure there are other implementation ideas. Comments would be appreciated.

2. resolving performance issues -> already shipped in v3.

Add arguments to some APIs that were known to have performance issues but were left in place because of potential compatibility breakage.

For example,

func BootTimeWithContext(ctx context.Context, useCache bool) {
   (snip)
}
func BootTimeWithContextWithCache(ctx context.Context) {
    return BootTimeWithContext(ctx, true)
}

Other issues with the performance label will be looked at carefully.

I was looking for a way to add a flag in ctx that would not break the API, but after some experimentation I decided that it would be less confusing to add it explicitly as an argument. I think it would be difficult to determine later if there is a problem.

Schedule

IMPORTANT NOTICE: I can only work on gopsutil mostly on weekends.

We will be calling for features on this issue for a while now, and by mid-December we will decide which features we want to include and set a release schedule. It will probably be after February 2024.

However, I am having physical problems at this moment. Depending on how it goes, there may be a further delay.

[shirou]

host.SensorsTemperaturesWithContext should be moved to new package, sensors. https://psutil.readthedocs.io/en/latest/index.html#sensors

[shirou]

I am thinking about introduce cache mechanism by using host.EnableBoottimeCache(true) function instead of adding args.

[Lomanic]

I don't have the energy to spend time on gopsutil these days (my hats off to you @shirou for keeping the lights up for all this time), but this time I would suggest to have a v4 branch to test things out before it's released and the API is set in stone, I don't remember we've done that for the v2 to v3 upgrade and I've been thinking for quite some time this was a missed opportunity.

[shirou]

@Lomanic, your commitment has helped me greatly. I have the deepest respect for you every time I see your very carefully written code and the extensive research you have done to back it up. Without you, gopsutil would not be so widely used and I would not have been able to continue. I would like to express my greatest appreciation.

And thanks for the suggestion. I haven't actually started development of v4 yet, but I also think it would be better to create a new v4 branch as you mentioned.

[shirou]

I have changed the status of the v4 PR to Ready for Review. There are probably still some specifications left to discuss, but I would appreciate it if someone could take a look and try to use with v4.24.0-alpha.1 version.

[shirou]

No response comes. So I will release v4 this month after porting current v3 development.

So at the end of April, there will be 2 tags.

• v3.24.4 (this is a final release of v3)
• v4.24.4

[shirou]

I want to include these issues in the v4 release. Therefore I want to move the release schedule to next month.

• [RFC] winver.exe output as platform version for windows hosts #1503
• Missing FQDN/hostname option for windows #1572
• [process][linux]collect rchar and wchar from /proc/${pid}/io #672

Then, end of this month the v4.24.0-beta will be released. and those two tags will be released at end of May.

• v3.24.5 (this is a final release of v3)
• v4.24.5