Not at all the same. These are three outputs from the same build process and code base. Maintaining a build with WebKit and one with Mozilla’s own rendering engine is like running a different team.
It’s not the same code base though. They’re all different branches, and also differ in code (although not by much, but it still requires manual maintenance of each branch). I haven’t seen the actual build process but it’s likely to be completely separate CI/CD pipelines, so I wouldn’t claim it to be the “same” build process either. Also, Focus uses a completely different UI with a different/cut-down set of features.
Naturally I’m not saying that maintaining these branches amounts to the same level of effort as maintaining the iOS WebKit and Gecko branches, but it’s not some non-trivial effort either.
It doesn’t have to be separate branches - you can generate different versions of the software from the same code branch, e.g. using compiler/build time switches for those bits of the code that differ between the different target platforms. Then you would have a build pipeline per platform; even here the build pipeline can share a lot of common code, and just be parameterized for the specific platform.
I didn’t realise Focus was a unique feature set. My apologies. I maintain my original comment on Nightly and Beta - if they aren’t using (almost) the same CI/CD pipeline, doesn’t it sort of defeat the purpose of each of these builds being a maturation towards a stable build? I’ve certainly never deployed software with a “daily/beta/stable” branch/feature-flag structure that wasn’t attempting to replicate the build process, with a view to catching issues upstream/pre-stable.
Lets not make this out to be like it’s Kerberos (more complicated than rocket science)… Making available another, region-specific version of your app isn’t difficult. It’s just the developer equivalent of an extra one-time TPS report (you have to setup/modify some build scripts and make some additional tests).
It’s the equivalent of having builds for .rpm and .deb and then adding a .AppImage build. It shouldn’t be that big a deal for the Mozilla Firefox team.
In fact, I bet they’re freaking excited at the prospect of being able to make a real build of Firefox for iOS.
Not at all the same. These are three outputs from the same build process and code base. Maintaining a build with WebKit and one with Mozilla’s own rendering engine is like running a different team.
It’s almost as if Apple is making this difficult.
It’s not the same code base though. They’re all different branches, and also differ in code (although not by much, but it still requires manual maintenance of each branch). I haven’t seen the actual build process but it’s likely to be completely separate CI/CD pipelines, so I wouldn’t claim it to be the “same” build process either. Also, Focus uses a completely different UI with a different/cut-down set of features.
Naturally I’m not saying that maintaining these branches amounts to the same level of effort as maintaining the iOS WebKit and Gecko branches, but it’s not some non-trivial effort either.
It doesn’t have to be separate branches - you can generate different versions of the software from the same code branch, e.g. using compiler/build time switches for those bits of the code that differ between the different target platforms. Then you would have a build pipeline per platform; even here the build pipeline can share a lot of common code, and just be parameterized for the specific platform.
I didn’t realise Focus was a unique feature set. My apologies. I maintain my original comment on Nightly and Beta - if they aren’t using (almost) the same CI/CD pipeline, doesn’t it sort of defeat the purpose of each of these builds being a maturation towards a stable build? I’ve certainly never deployed software with a “daily/beta/stable” branch/feature-flag structure that wasn’t attempting to replicate the build process, with a view to catching issues upstream/pre-stable.
Lets not make this out to be like it’s Kerberos (more complicated than rocket science)… Making available another, region-specific version of your app isn’t difficult. It’s just the developer equivalent of an extra one-time TPS report (you have to setup/modify some build scripts and make some additional tests).
It’s the equivalent of having builds for .rpm and .deb and then adding a .AppImage build. It shouldn’t be that big a deal for the Mozilla Firefox team.
In fact, I bet they’re freaking excited at the prospect of being able to make a real build of Firefox for iOS.