Timing for release of NVDA Add-Ons to the Add-On Store during beta testing . . .

[britechguy]

Detailed description of the issue

At the moment, NVDA Add-Ons for backward compatibility breaking NVDA releases are not placed into the NVDA Add-On store prior to a release reaching RC status. It's becoming increasingly clear that this really is too late, and that it also prevents a number of people who might be willing to test betas from doing so because they simply cannot access any of the add-ons that they use.

For those developers who are creating versions of their add-ons that are compatible with the next NVDA release that have those "waiting in the wings," sometimes even prior to beta releases, these should be able to be placed in the NVDA Add-On store for the beta period.

Why are the other templates not appropriate in this case?

This isn't about NVDA software, per se, so most of the questions that relate to either a bug report or feature request are not pertinent.

This is really "a business decision" about when something that already happens is allowed to happen. I believe it should be earlier in the process than it is currently.

Have you asked for advice on how to report this issue via a community discussion? If so, please link to the discussion

No.

[seanbudd]

This is not something we can really take action on. We can't mark the API as stable before the RC. We could extend the RC period, meaning that the stable release comes out 2-3 weeks after the RC, to give add-on developers more time. However, I feel this is not of benefit to users. Getting the release out ASAP keeps our releases agile. Waiting harms those who don't want to wait for add-ons. Those who want to wait still can wait, and those who don't want to wait don't have to.

We do not place any pressure or expectations for add-on authors to release stable add-ons before a stable NVDA release. Add-on authors are encouraged to take the time they need to release a stable add-on. We encourage NVDA users to wait patiently for their add-ons to be updated. Many NVDA users will hold off on upgrading until add-ons are updated and that is totally fine. They can also consider using incompatible add-ons, or beta/dev add-ons if they are willing to take the risk and not wait.

[seanbudd]

Prior to the RC period, add-on authors can release add-ons to beta/dev channels, which means testing can occur.
We can't push releasing a stable add-on before the RC.
Assume an add-on is released and marked as stable and compatible with the last planned beta, which corresponds to the start of the translation freeze.
Then, if API changes happen after the translation freeze is announced, that add-on could be broken with the new API.
That means if the stable or RC release comes out, a user could install this add-on, assuming it is safe with the RC/stable release, and have it totally break their NVDA installation.

[britechguy]

We can't push releasing a stable add-on before the RC.

About which we're in complete agreement. But it seems that quite a few add-ons are already in "usable with 2025.1" state based on things said by their respective developers on the NVDA group. But none seem to make it into the beta channel, and perhaps encouraging the developers to put them there would get the end result I'm looking for.

When I see developers say that they have made the changes needed for a backward compatibility breaking release, have tested these with alpha builds, and that, by their estimation they're just waiting for NVDA, it seems there should be a way that they could be available during the beta period.

I had not remembered that a beta channel exists in the Add-On store, and were it to be used more, and NVDA betas could install add-ons from it, that would fix the issue I'm having.

I have resorted to using incompatible add-ons, but would prefer to avoid that when one that's stated to be "ready and waiting" by a developer exists. But it appears that many are not placing these into the beta channel of the Add-On Store.

[seanbudd]

All add-on authors should be following our API mailing list which provides updates during the release process and encourages authors to release beta/dev add-ons.

I do agree that we should probably change the default channel viewed in the installable/updatable add-ons tab on alpha/beta NVDA versions to "all" not "stable"

[josephsl]

Hi,

I intentionally decided not to post add-on builds on beta channel for two reasons:

1. Most of the add-ons I'm "maintaining" (in quotes) mostly include localization updates with no changes to the actual add-on code.
2. To simplify update channels and releases.

While I might not be able to do this (as I want to seriously transition to a different role with this project - away from add-on development for real this time), one suggested compromise is releasing beta builds as soon as translatable string freeze is announced. This ensures beta users will receive the latest compatible releases at least two weeks earlier. The reason for this is that betas can (and have) include incompatible changes at the last minute, and if an add-on happens to rely on the said changes, it will require developers to rewrite parts of their add-on to deal with the sudden change in API (how long this will take depends on the add-on author's familiarity with the changed code in NVDA itself). Also, keep in mind that, apart from a brief period in the beginning of a year, beta releases will be almost continuous, and this means asking add-on authors to maintain up to three update channel releases if folks chose to release beta add-on releases when NVDA year.x beta 1 is published.

Postscript: I truly meant it when I said I want to move away from add-on development for real this time as things came up that will require me to take a long-sought break from NVDA project.

Hope folks understand this.

Thanks.

[britechguy]

All add-on authors should be following our API mailing list which provides updates during the release process and encourages authors to release beta/dev add-ons.

I get the feeling that many really are not. In checking just now, the only one of the Add-Ons I have that was in the Beta Channel is MathCAT.

The following is NOT meant to cast aspersions or blame, but I don't see any of Joseph Lee's add-ons in the beta channel, and I'm virtually certain that he's got a number "ready to rock and roll" for NVDA 2025.1. When his stuff is missing, and I'd have suspected it would likely have been some of the first to be in there, I'm reading a lot into that for what it implies about the use of the beta channel of the Add-On Store. I could be completely off-base, and will admit that. It just seems that based on NVDA Group chatter and some of what I've seen in the NVDA Add-On Developer's Group, that quite a few add-ons should already be in the beta channel of the Add-On Store.

[britechguy]

I truly meant it when I said I want to move away from add-on development for real this time as things came up that will require me to take a long-sought break from NVDA project.

I have no doubt, but, Joseph, until and unless you actually do, you are still in the developer role. And, for good or for bad, are often looked to as "the model to emulate."

You simply cannot keep having it both ways, and if you need to step out of the role, you should. But you simply cannot keep playing both sides of the fence, and you have been for years, several years, now.

[josephsl]

Hi,

Brian is right - I do acknowledge my role model status, yet for this instance, I should have thought more about lack of beta channel add-on releases and impact on this decision on users.

As for my role, I've been slowly moving away from the developer role. Yet a part of me is still obsessed with add-on development and a constant nagging feeling to keep them updated - at least once a year to update compatibility information. I think part of this may have to do with my annual anxiety about add-on compatibility around compatibility breaking releases and how I respond - update add-ons, knowing that folks will ask questions about add-on compatibility. The other part might be my over-protectiveness toward my add-on creations, something I return to from time to time despite a personal reminder not to feel that way.

I am very careful about saying this on a public venue like GitHub, but sometimes when I work on NVDA and/or add-on development, I feel as though I am not myself, more specifically that I do so for sake of others more than for my own sake. I was looking for a way out, and I thought I had it this year when I announced impending end of life of Windows App Essentials because that was the only add-on anchor keeping me to the NVDA community as a developer. Then when the opportunity to refactor StationPlaylist add-on came up, I decided to take that on, knowing that this was it or never (my plan is to end the refactoring work in June so by the time StationPlaylist add-on 25.07 is released in July, I can finally raise my hand and say, "this is it from me"). In short, I'm trying my best to balance the need for me to have a clean break from the developer role versus giving users one final gift in the form of updated and compatible add-ons, and I confess that right now I'm doing a terrible job at both.

Thanks.

[CyrilleB79]

Interesting discussion pointing a real feeling in the users community.

First, I'd like to say that real late incompatibility situations may occur during beta dev cycle.
This juste happened for my Character Information add-on. On May 19th, the translation freeze has been announced and beta6 has been released. At the same time, Character Information add-on stopped working due to the release of #18102 in beta6.

To describe my own add-on author experience:
I am one of the add-on authors who have stopped releasing dev or beta versions of my add-ons to avoid the extra work of making and testing specific releases for these channels. When the add-on store has been developped, I had asked the possibility to release the same add-on bundle through different channels but this has not been accepted.
If this choice is reconsidered in the future, i.e. if we can distribute the same release through beta and stable channel, I probably will distribute my add-ons through beta channel when needed.
Though, I doubt this architectural choice will be reconsidered in the near future.

[SaschaCowley]

We have identified several concerns above. Any suggestions for how to proceed need to take these concerns into consideration.