Release Management/Rapid Betas: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 108: Line 108:
'''Update''' - RelEng (and lsblakk) met and discussed the complete process of releasing betas and have scoped the work involved in meeting this project's goals [https://wiki.mozilla.org/ReleaseEngineering/Rapid_Release_Nightly_Betas#Live_Notes here]
'''Update''' - RelEng (and lsblakk) met and discussed the complete process of releasing betas and have scoped the work involved in meeting this project's goals [https://wiki.mozilla.org/ReleaseEngineering/Rapid_Release_Nightly_Betas#Live_Notes here]
== Questions ==
== Questions ==
* What should we call beta nightlies (Rapid Betas)?
* What should we call beta nightlies (Rapid Betas)? A: Daily Betas (and we are not 'announcing' this like it's something new we're doing)
* How do we communicate beta nightlies?
* How do we communicate beta nightlies?
* The beta release process is a useful tool for verifying the final release process. If we change the final release process, how will we verify the changes or bring new people up to speed without affecting the timing of the final releases?
* The beta release process is a useful tool for verifying the final release process. If we change the final release process, how will we verify the changes or bring new people up to speed without affecting the timing of the final releases?
Line 124: Line 124:


In summary:
In summary:
- Using Rapid Builds we will be able to push bug fixes faster.
- Using Daily Builds we will be able to push bug fixes faster.
- Rare signatures will be picked up later (once enough reports come in) and in this regard Rapid Builds is not much different from weekly builds.
- Rare signatures will be picked up later (once enough reports come in) and in this regard Daily Builds is not much different from weekly builds.


= Product Marketing & PR =
= Product Marketing & PR =
Confirmed users
4,467

edits

Navigation menu