7.16.20 has been released for Windows for quite a while now, but I still couldn't find any change log or release notes. The wiki ended at 7.16.19: https://boinc.berkeley.edu/wiki/Release_Notes. The pinned threads here ended a bit earlier. Github doesn't seem to have a summary for version changes. Where do we post release notes now?

---

We're out of volunteers to write them.

If the developers can't be bothered to write them... I essentially stopped writing them because it was quite a bit of work and thought that after all these years someone else could do it, get them out of the source code and post them. I'll sticky them.

No one else stepped up to the fray either, everyone is pointing to someone else. 🤷🏼‍♂️

If the developers can't be bothered to write them... I essentially stopped writing them because it was quite a bit of work and thought that after all these years someone else could do it, get them out of the source code and post them. I'll sticky them.

No one else stepped up to the fray either, everyone is pointing to someone else. 🤷🏼‍♂️

Interesting. I can kinda understand writing code is different kind of work of summarizing all changes. Is the process mostly about reading github commit logs and try to summarize interesting findings between two versions? Or is it looking at issues closed in github? I can give it a shot, though I need someone to guide me through the initial process and review whatever I produce.

What prompted me to ask this is the "unverified" tags status on github for 7.16.20: https://github.com/BOINC/boinc/tags. Given all the supply chain attacks on open-source projects recently, I am bit worried about what 7.16.20 contains, which is why I am trying to find release note and hoping that at least have a chance of catching anything odd going on.

Might as well try directly I guess? This one looks fairly short: https://github.com/BOINC/boinc/compare/client_release/7.16%2F7.16.19...client_release/7.16/7.16.20

* Correctly report Windows 11
* Notify user to detach/reattach to a project if its master URL changes

Ignored the CA update. I supposed it's regular maintenance. Ignored the http to https transition part since that's the same behavior as before. Let me know how this looks.

PS: What a coincidence. I just updated to Window 11 last weekend. After reading the log I immediately checked my client log and well it's indeed reporting Windows 10 on 7.16.19. Now that I know what this version is for, I updated to 7.16.20 and it then reports Windows 11 correctly. Cheers.

You can't decide to ignore certain uodates or parts thereof. How is a user to know that you decided to leave possible key updates out only because you 'feel' they don't belong?

Especially in these, without the CA update BOINC wouldn't be able to connect to certain projects whose certification has expired.

You're already omitting parts based on your gut feeling and this update only had four lines? How's that going to be when an update has 30-40 lines, or more even?

The fun part starts with whole new clients, when the major number changes from 7 to 8, those are usually all lifted from Master and it's not clear if updates actually made it into the new client, or not. And that's when you then ask the developer or release manager.

But you never decide on your own title that updates shouldn't be listed just because...

The preparation of release notes is in the documented 'process' section of https://github.com/BOINC/boinc-policy/blob/master/Development_Documents/Client_Release_Process.md. An individual known as the 'Release Manager' is responsible for overseeing the process overall, but doesn't have to do each step themselves.

When I was asked to fill this role (briefly - for one time only) for BOINC v7.10, I didn't do the release notes directly myself, but I asked Jord if he could help out, and gave him the best list I could of the significant changes.

Unfortunately, the current (self-appointed) Release Manager seems neither to prepare the notes himself, nor to nominate or request somebody else to do them for him.

You can't decide to ignore certain updates or parts thereof. How is a user to know that you decided to leave possible key updates out only because you 'feel' they don't belong?

Especially in these, without the CA update BOINC wouldn't be able to connect to certain projects whose certification has expired.

You're already omitting parts based on your gut feeling and this update only had four lines? How's that going to be when an update has 30-40 lines, or more even?

I had the impression from reading previous notes that they focus more on bug fixes and features. This is also how it's described in the link I just got now:

> The release notes should be created/updated each time a build is made from a release branch. The information in the release notes should contain the new features and important bugs fixed since the previous release.

There is no definition of "important bug fixes". For example, this fix for a crash doesn't seem to be in any release notes. There is probably some decisions made to make the release note more useful for its audience, which is the process I was asking about.

Regarding the CA update, I left it out not because of my "gut feeling". I said "I supposed it's regular maintenance". I meant exactly what you spell out here that the client could stop working with projects without these commits, so it's not that user can make meaningful decisions based on that information. On the other hand, I agree with you now that this should be included. If someone is trying to figure out why they can't connect to projects, they likely want to know CA cert updates happened between their old version and the latest one. That's important enough to be noted and it's a mistake to leave it out.

But you never decide on your own title that updates shouldn't be listed just because...

That's why I said: "I can give it a shot, though I need someone to guide me through the initial process and review whatever I produce. " I am not "deciding on my own" here, but someone has to propose a draft to start the discussion, right?

I don't see how I left the impression of making decisions as if what I wrote should be final from my previous reply. Obviously whatever i produced needs to be reviewed.

The Release Notes Richard's documentation points at are the official ones which do omit things sometimes.

Because that always irked me, I started gathering all of them, first manually going through all commits on SVN, later Trac, and later Github. Although here I also used some grep commands to go through the long lists of updates, and it's why I have the disclaimer "The actual change log was taken from the Alpha email list and the Github Timeline repository changes check-ins, but it can happen that changes in the list are missing, double, or misplaced.", in case parts are in the list I wrote that aren't in the client/manager, or they are in there but not in the list.

I no longer have the source code on my computer, nor am I interested in getting it again, which is the main reason why I quit writing the change logs. You can do it however you want, but I just plead to you, don't follow the 'official method' because then you're just telling the users that some changes in the log are need to know - and they don't need to know.