On Mar 18, 2023, at 20:33, Joseph Lee <joseph.lee22590@...> wrote:

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Christopher Duffley
Sent: Saturday, March 18, 2023 6:50 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Not sure ,if you saw a previous message but as a starter add-on for me, I'd be willing to keep up with ObjPad for now. I'll still keep SPL and will see what I can do over time. I'm still in the learning stages for Python and NVDA source code, hence my previous statement.

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

• Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
• Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Day Garwood
Sent: Sunday, March 19, 2023 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi Joseph,

I'm willing to have a bash at maintaining GoldWave, though how much use I'll be is another story...I certainly won't be able to do anything with it immediately. I've had a look at the code and at present I haven't a clue what I'm doing. It'll take a lot of learning, but I haven't a clue where to start. I already know basic Python syntax but beyond that I'm a relative newby.

Also, is Git and Github a requirement? If so that's something else I'll need to learn.

Cheers.

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

1. Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
2. Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

Hi,

Git and GitHub are required if you would like to keep track of changes and/or publish add-on releases to the add-on store. One thing about GoldWave add-on: being a GoldWave user helps in maintaining the add-on more effectively.

Cheers,

Joseph

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Day Garwood
Sent: Sunday, March 19, 2023 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi Joseph,

I'm willing to have a bash at maintaining GoldWave, though how much use I'll be is another story...I certainly won't be able to do anything with it immediately. I've had a look at the code and at present I haven't a clue what I'm doing. It'll take a lot of learning, but I haven't a clue where to start. I already know basic Python syntax but beyond that I'm a relative newby.

Also, is Git and Github a requirement? If so that's something else I'll need to learn.

Cheers.

 

On 19/03/2023 00:33, Joseph Lee wrote:

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

1. Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
2. Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Day Garwood
Sent: Sunday, March 19, 2023 7:27 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi Joseph,

Yes, I am a GoldWave user.

Hi,

Git and GitHub are required if you would like to keep track of changes and/or publish add-on releases to the add-on store. One thing about GoldWave add-on: being a GoldWave user helps in maintaining the add-on more effectively.

Cheers,

Joseph

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Day Garwood
Sent: Sunday, March 19, 2023 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi Joseph,

I'm willing to have a bash at maintaining GoldWave, though how much use I'll be is another story...I certainly won't be able to do anything with it immediately. I've had a look at the code and at present I haven't a clue what I'm doing. It'll take a lot of learning, but I haven't a clue where to start. I already know basic Python syntax but beyond that I'm a relative newby.

Also, is Git and Github a requirement? If so that's something else I'll need to learn.

Cheers.

 

On 19/03/2023 00:33, Joseph Lee wrote:

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

1. Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
2. Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

Hi,

GoldWave transfer queued for March 25, 2023 (GitHub username, please). As always, do ask around for help if you get stuck.

Cheers,

Joseph

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Day Garwood
Sent: Sunday, March 19, 2023 7:27 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi Joseph,

Yes, I am a GoldWave user.

Cheers.

 

On 19/03/2023 14:13, Joseph Lee wrote:

Hi,

Git and GitHub are required if you would like to keep track of changes and/or publish add-on releases to the add-on store. One thing about GoldWave add-on: being a GoldWave user helps in maintaining the add-on more effectively.

Cheers,

Joseph

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Day Garwood
Sent: Sunday, March 19, 2023 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi Joseph,

I'm willing to have a bash at maintaining GoldWave, though how much use I'll be is another story...I certainly won't be able to do anything with it immediately. I've had a look at the code and at present I haven't a clue what I'm doing. It'll take a lot of learning, but I haven't a clue where to start. I already know basic Python syntax but beyond that I'm a relative newby.

Also, is Git and Github a requirement? If so that's something else I'll need to learn.

Cheers.

 

On 19/03/2023 00:33, Joseph Lee wrote:

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

1. Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
2. Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

From: Joseph Lee
Sent: 19 March 2023 01:33
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

1. Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
2. Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Kefas
Sent: Sunday, March 19, 2023 10:38 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hi joseph, I thought Luke was okay with me taking resource monitor?

 

I’m still okay with whatever you decide.

 

Sent from kefaslungu

 

 

Hi all,

Two notices regarding my add-ons, one regarding end of life add-ons:

1. Add-on repository transfers: I will begin the transfer process on March 20, 2023 shortly after releasing Event Tracker and Sound Splitter 23.04 releases. The process will involve tagging 23.04 from my repo, publishing 23.04 package to add-on store and community add-ons website, transferring repos, then announcing the new repo locations once the new maintainer(s) accept transfer requests. The first add-ons to be transferred will be Event Tracker and Sound Splitter to Luke Davis on March 20th, followed by Enhanced Touch Gestures to Kefas on March 23^rd, Resource Monitor to Luke and StationPlaylist to Christopher on March 24^th, then to whoever wants to maintain GoldWave, Object Location Tones, ObjPad, and Office Desk. If I do not hear offers for maintaining the last four add-ons by March 27, 2023, then I will archive the add-on repositories unless someone does offer to maintain them, in which case I will reopen the add-on repo transfer process. The absolute deadline for submitting late transfer requests (after March 2023) will be May 31, 2023 or a week after NVDA 2023.2 stable version is released, whichever happens later, and if no-one steps up to maintain end of life add-ons, then I’ll consider these add-ons abandoned for the purposes of record keeping (as in declaring these add-ons legacy on community add-ons website). Please help me by offering to maintain end of life add-ons (sooner than later), more so as add-ons will need to be tested and updated when NVDA moves to newer Python releases.
2. Version schemes for dev and beta add-on releases: depending on community consensus and recommendations from NV Access regarding add-on store and versioning, I may change versioning scheme for dev and beta channel releases after a transition period (variation of calendar versioning is ideal). Currently dev channel releases are named yyyymmdd-dev e.g. 20230319-dev. Unless the add-on store submission form allows entering custom version names and numbers instead of fetching it from add-on manifests, future dev channel releases will be named yyyymmdd.0.revision/patch e.g. 20230319.0.0 (in case more than one daily dev builds are released). Same with upcoming beta channel releases except version string is not settled yet – likely either yyyymmdd.1.revision/patch (1 denoting beta channel), year.month.higherNumberedPatch (say, 10 or above), or year.month.day, or something suitable. In case of dev channel builds, putting 0 (zero) in the middle of the version name acknowledges the historical use of dev channel builds to test what amounts to beta channel releases in add-on store, and the tendency to release dev builds from the primary branch (master/main/whatever), as well as noting that current sconstruct file from add-on template names dev channel builds as yyyymmdd.0.0 (speaking of sconstruct file, you can release beta builds if you pass in channel=beta in command-line arguments when running scons, along with specifying version and versionNumber parameters; perhaps a dedicated beta=true option could be useful in the future). While the possible version scheme applies to add-ons I’m maintaining or letting go, it will impact Windows App Essentials the most as this is the only add-on from me with frequent dev channel releases at the moment (almost daily). Feedback on the possible version scheme is appreciated.

 

Cheers,

Joseph

On Mar 18, 2023, at 21:52, Joseph Lee <joseph.lee22590@...> wrote:

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Christopher Duffley
Sent: Sunday, March 19, 2023 11:21 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Joseph Lee's add-ons: repo transfers will begin on March 20, 2023, dev/beta versioning scheme for add-ons going forward

 

Hello,