bump version to v4.4.0, setup for release

[theodoregoetz]

Following the forum discussion, I propose to create a new release v4.4.0 (libtool/soversion 5.2.6). Initially, I dumped the git log into the NEWS file, this can be cleaned up before merging to master.

[bluca]

This is not useful. Apart from getting the versions wrong, and apart from the mess with whitespace changes, dumping git log into NEWS doesn't help, it needs to be curated. If you want to help, you can do manual QA on Windows/OSX/QNX/Solaris/BSD* and so on.

[GauravAccGit]

@bluca @theodoregoetz Kindly update when can the issue #4550 be fixed and new version be created

[bluca]

when it's ready

[joubertdj]

@bluca : To quote you on your on "statement": "This is not useful".

If you followed the e-mail discussions regarding all the downstream issues a non-release by libzmq is doing you would understand why even a small point release will help the community at large. That someone, either than you, took initiative to start this process, should be commendable. There was only one CI build/test that failed ... one of sixteen ...

Why close the PR when several members wants to help/assist in releasing a point release? What is YOUR reason for closing it and when do YOU think it will be sufficient for releasing? Don't give us the "white-space" answer, we might not be super-coders-walking-on-water, but our noses do still work. Everybody is replaceable, and I learned that unfortunately the hard way.

Can we have clear milestones for what needs to be done to get a release out please?

[bluca]

What's needed is written here: https://github.com/zeromq/libzmq/pull/4550#issuecomment-1550027670 IE, it's real work that is needed for the next release (no, blindly dumping git log is not it), just as it was needed for all past releases, so either go head and do it, or pay somebody else to do it, or sit down and wait patiently until somebody else does it. Given as far as I am aware you are not paying my salary, and you have never contributed anything either, you can take that self-entitled attitude and bring it somewhere else, as nobody here owes you anything.

[theodoregoetz]

@bluca kindly reopen this merge request and I'll gladly change the version number to whatever you want, cleanup white space issues and attempt to "curate" the change log as requested. I may be able to do manual testing on some of the systems you mentioned but probably not all (Windows/OSX/QNX/Solaris/BSD*). A few questions though: is Windows 7 or 10 (or 8 for that matter) still important here? I assume you mean macOS instead of OSX. I can test on Intel and M1 chips on 11.x and 12.x. The remaining issue then is what do you mean by "manual QA"? Is it something more that is not typically caught in the merge process?

Again, please reopen this issue if you'd like these to be fixed. Thank you.

[bluca]

Manual testing means what it sounds - download, compile and run unit tests and local tools on the given platform. As it can be seen from the list of CI jobs, only a small subset of platforms is covered. The list of supported platforms is in the readme.

Please open a new PR, doing one thing at a time. Leave the versions alone, start with a curated changelog.

[theodoregoetz]

@bluca If more than one merge request is required to increment the version, could you please create a milestone with the issues that detail the exact PRs you expect and the exact version you expect to target? This would greatly help the community at large to help you.

While I understand you think this has little value, there are many that would benefit from a simple version bump judging by discussions on the mailing list. There is no need to reiterate your assertion that issue trackers are not to be used for discussion. This will be my last comment on this thread unless I'm asked a specific question.

[GauravAccGit]

Hi Team, just checking if any update on when can the new zmq version be released