Nightly Builds & Safari Extension Beta Builds?
Is there anything particular to know about before opting for the "nightly" builds? Will release notes be available for those builds? Also, how can we get access to the latest beta build of the 1Password browser extension for Safari, because the only option available right now is the Mac App Store version (2.0.6).
Thanks
1Password Version: 1Password 8 Early Access (8.2.2-x)
Extension Version: Safari: 2.0.6; Others: 2.1.0
OS Version: macOS 11.5.2 (Intel)
Comments
-
Hi @nimvio ,
The short version nightly builds are "more beta than beta", and we don't have plans to offer beta 1Password for Safari releases in the near future.
Nightly builds
Most users would be better served on the
PRODUCTION
orBETA
channels. You'll get to see new features sooner onNIGHTLY
, but it can be a bumpy ride.We built the
NIGHTLY
channel for us, but kept it visible to allow curious users to explore. We use agit
workflow that is based on Merge Requests (MRs). When we're building a new feature, or working to solve a bug we branch frommain
. A gitlab MR is required to bring those changes back intomain
. This review requires at least one other developer to approve. Particularly sensitive areas of the code (like cryptography) are further protected with gitlab's Code Owner feature. Changing those areas requires reviews and approvals from specific teams.The merge request runs a variety of automated tests before merging into
main
. These range from static analysis tools likelint
or clippy to more traditional unit tests and Build Verification Tests (BVTs).Typically once per day, a
NIGHTLY
release is automatically built from the current state ofmain
, and is automatically tested and published. Sometimes aNIGHTLY
release will be skipped because something broke in the pipeline. Sometimes we'll be working on the updater, and we may trigger a dozenNIGHTLY
releases in a single day.We branch from
main
when we're ready to create a newBETA
. Our QA team runs though Release Candidate Tests (RCT). If an important issue is found, we'll create a MR to fix it, review and merge the fix intomain
, and thengit cherry-pick
the change into our release branch and create a new build. Once we're satisfied with the release, we manually start the jobs to publish the beta.The process for
PRODUCTION
is similar toBETA
. Instead of basing the release freeze branch onmain
, we base it on the previousBETA
release. We'llcherry-pick
fixes into the release freeze branch, make a new build, and QA will run tests on it.1Password for Safari beta releases
Distributing Safari Web Extensions is complex. Either users would need to allow unsigned extensions or the beta extension would need to be distributed in TestFlight via the Mac App Store. Allowing unsigned extensions is dangerous, and there are very few legitimate reasons to do so. We're not going to encourage our users to disable that safety feature, which means our only option for beta distribution is TestFlight.
TestFlights for the Mac App Store are very new. If you look at https://testflight.apple.com/, it still says "TestFlight is not available for Mac apps." Apple started to role out the ability to run Mac TestFlights this summer. Currently Mac App Store TestFlights are limited to the macOS Monterey Preview.
I wouldn't say we'll never do public TestFlights for the browser extension, but we don't have any plans to do so.
Edit: I was incorrect about the Apple Silicon requirement for TestFlight on macOS.
0 -
Currently Mac App Store TestFlights are limited to Apple Silicon hardware running the macOS Monterey Preview
Are you sure about that?
I'm running several TestFlight beta's in my macOS Monterey VM in Parallels Desktop on my (Intel) MacBook Pro (16-inch, 2019).
0 -
@XIII Thanks for the correction. 😅
I had misinterpreted the WWDC session.
It supports native Mac apps and iOS apps on Apple Silicon Mac.
I now realize they meant that you can use TestFlight to test Mac apps on Intel hardware running Monterey, and you can test both Mac apps and iOS apps on Apple Silicon.
0