Re: FW: [Nvda-devel] Changes to release process


David Moore
 

Hi Joseph!

Thanks a lot.

I like using the latest code possible, so I will use the alpha snapshots. I will make comments on how everything is working in that snapshot.

David Moore

               Sent from Mail for Windows 10

 

From: Joseph Lee
Sent: Thursday, July 5, 2018 7:27 PM
To: nvda@nvda.groups.io
Subject: [nvda] FW: [Nvda-devel] Changes to release process

 

Hi,

Please read Mick's follow-up post below. Thanks.

Cheers,

Joseph

 

-----Original Message-----

From: Mick Curran <mick@...>

Sent: Thursday, July 5, 2018 3:32 PM

To: NVDA screen reader development <nvda-devel@...>

Subject: Re: [Nvda-devel] Changes to release process

 

Hi all,

 

 

The Release process article has been updated again based on user feedback.

 

 

The most important parts are in the Changes for Testers:

 

* The next branch and next snapshots will no longer exist. Anyone currently on a next snapshot will be automatically updated to new "alpha" snapshots. Alpha snapshots are created directly from Master each time it changes (I.e. when a pull request is merged). As the name suggests, these snapshots are alpha quality. And although automated tests pass, these builds have had no user testing.

  * Anyone currently on master snapshots will be upgraded to the first available tagged beta for the current release. Beta builds, as the name implies, are beta quality and have had some testing by users. Note that as new betas are made available you will keep automatically upgrading, and then also upgrade to the final stable release. To get back to beta testing for the next release you will need to manually download a new beta for that release.

  * The snapshots page at https://www.nvaccess.org/files/nvda/snapshots/

now lists both alpha snapshots and all beta releases.

 

Everything is now in place and snapshots should now start  asking to upgrade to their respective new version types.

 

 

Please note: as the new Alpha snapshots are based on current master, not

all previously incubating PRs are yet included. E.g. wxPython4 is not 

yet in the alpha snapshots. These previously incubating PRs will be

merged within the near future when we are sure the infrastructure is

working.

 

 

Mick

 

 

 

 

 

On 4/07/2018 6:28 PM, Mick Curran wrote:

> Hi Brian,

> I appreciate your constructive feedback. We will certainly think about

> your proposal and see what we can manage.

> Although we have published the new process, we have not yet removed

> any branches or switched anyone over, so we can still make some

> changes before committing to this fully.

> The reasons for sticking with the name master for the default

> development branch are:

> 1. We don't want to break existing pull requests which are currently

> open against master. There are more than 40 or so.

> 2. We don't want new contributors submitting pull requests against an

> old (defunct) version of master (if we do move).

> 3. master is the generally accepted name for the default branch of git

> repositories for most projects on github.

> There may be another way to solve this specifically for snapshots.

> I'll have to research this further.

> We will wait for more feedback and think on this more.

> Mick

> But,

> On 4/07/2018 4:59 PM, Brians old account via Nvda-devel wrote:

>> While I can see the reasoning for this change. I do think that a

>> number of us are going to have to do the following. When the Next

>> becomes master, we are going to have a period when the new beta

>> branch does not exist, Now taking my own case as a for instance. I

>> currently use master as my working version though I of course do have

>> a portable of the latest stable version, That will mean if I do

>> nothing result in effectively my master becoming next, which means my

>> normal copy is now bleeding edge code. I may have to wait till the

>> new beta is created for the ability to change this around, and make

>> next master and master beta. Would it not be more sensible to  just

>> remove master, and use next as you propose master is to be, then

>> create a new beta when applicable?

>> That way  folk used to using master as pretty stable will not be

>> affected. They will stay on master, then when a new beta comes out

>> they will be migrated to this for their  working versions.

>> if you want users to participate, as I think is a good thing, in my

>> view the proposal I outline above will carry more people with you.

>> also please remember to formerly tell people on the user list about

>> what you are doing so you do not suddenly find a lot of folk with

>> problems.

>> I do realise that there are now a lot more checks  done

>> automatically, but in the end its the user that will be  running the

>> code more than anyone else, and feedback from that cohort of people

>> is worth its weight in gold. we all know that  many programmers are

>> the worst testers as they are predictable. its the newbie and the

>> less confident user who finds the bugs.

>> So what do you think?

>> 

>> Brian

>> 

>> bgaff@...

>> Brian Gaff's other account.

>> 

>> ----- Original Message ----- From: "Mick Curran" <mick@...>

>> To: "NVDA screen reader development"

>> <nvda-devel@...>; <nvda-translations@groups.io>

>> Sent: Wednesday, July 04, 2018 2:43 AM

>> Subject: [Nvda-devel] Changes to release process

>> 

>> 

>>> Hi contributors,

>>> 

>>> 

>>> We have made some small changes to the NVDA release process. Please

>>> read the updated Release Process article carefully to understand the

>>> changes and how they will affect you.

>>> 

>>> https://github.com/nvaccess/nvda/wiki/ReleaseProcess

>>> 

>>> 

>>> In short, Next/incubation is going away, and prs are going to be

>>> merged straight to master. Periodic betas will be offered startin

>>> from 5 weeks before a release.

>>> 

>>> Please read the entire article to understand the changes fully.

>>> 

>>> 

>>> Translators should not be directly affected by this change. Though

>>> technically, translations are now based on a new "beta" branch

>>> rather than master.

>>> 

>>> 

>>> Mick

>>> 

>>> 

>>> 

>>> 

>>> 

>>> 

>>> 

>>> 

>>> 

>>> --

>>> --

>>> Mick Curran

>>> Executive Director, NV Access Limited

>>> PH: +61 7 3149 3306 ext. 101

>>> www: http://www.nvaccess.org/

>>> Twitter: @NVAccess

>>> Facebook: http://www.facebook.com/NVAccess

>>> 

>>> 

>>> ------------------------------------------------------------------------------

>>> 

>>> Check out the vibrant tech community on one of the world's most

>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

>>> _______________________________________________

>>> Nvda-devel mailing list

>>> Nvda-devel@...

>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel

>>> 

>> 

>> 

>> ------------------------------------------------------------------------------

>> 

>> Check out the vibrant tech community on one of the world's most

>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

>> _______________________________________________

>> Nvda-devel mailing list

>> Nvda-devel@...

>> https://lists.sourceforge.net/lists/listinfo/nvda-devel

 

--

--

Mick Curran

Executive Director, NV Access Limited

PH: +61 7 3149 3306 ext. 101

www: http://www.nvaccess.org/

Twitter: @NVAccess

Facebook: http://www.facebook.com/NVAccess

 

 

------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________

Nvda-devel mailing list

Nvda-devel@...

https://lists.sourceforge.net/lists/listinfo/nvda-devel

 

 

 

 

Join nvda@nvda.groups.io to automatically receive all group messages.