Navigator wrote: ↑2024-03-13, 18:59
How much administrative overhead it would cost to provide a couple of different builds for each release?
Less than it would be for Pale Moon, honestly. Really, the main problem is Linux. Pale Moon has to do GTK2 and GTK3 versions of any build they offer, so they have to either enforce AVX on all builds or offer four versions because they don't want to go with some kind of odd logic like "GTK2 is the 32-bit of Linux" or something. On the other hand, I already said no to GTK2 for Linux, so I would only need to do one extra build.
The problem is that because of the way I do releases, all of them are a huge administrative overhead and require a lot of manual work on my part when I get ready to do one. Here's the process of doing an Epyrus release:
1. Decide which platform commit to use, and update the platform commit pointer on the Epyrus repo.
2. Update version.txt within the Epyrus repo to reflect the new Epyrus version.
3. Verify that everything builds and runs properly on all platforms.
4. Create a new release tag on the Epyrus repo referring to this version so I can roll back and see exactly what went into this version later on.
5. Open up MozillaBuild on Windows, and cd into the Epyrus source code directory on my hard drive.
6. Open up Git Bash, and also cd into the Epyrus source code directory on my hard drive.
7. Type
git checkout Epyrus2.x.x_Release in the Git Bash window.
8. Type
git submodule update in the Git Bash window.
9. Type
notepad .mozconfig and verify my .mozconfig is correctly setup for a 32-bit build so I can do that first.
10. Type
./mach build in the MozillaBuild window to do a 32-bit build.
11. Wait for the build to finish, and then use
./mach run to verify everything built properly.
12. Type
./mach package && ./mach installer && ./mach mar && ./mach mozpackage to generate the base 7z package (required to generate the installer and mar), the Windows installer, the update MAR, and a zip file for distribution.
13. Type
ls obj*/dist to make sure everything is in the directory that should be.
14. Repeat step 9, but this time setup my .mozconfig for a 64-bit build.
15. Repeat step 10.
16. Repeat step 11.
17. Repeat step 12.
18. Repeast step 13.
19. Use the
./mach updater-xml command I built into my perl-based mach stub to generate update xml files for both the 32-bit and 64-bit builds after they are built. (I couldn't figure out shell scripting well enough to do it as a cross-platform thing, and perl is a build requirement anyway).
20. Type the currently released version of Epyrus and verify the files were generated correctly.
21. Open up a virtual machine running CentOS 7 and get to a terminal window.
22. cd into the Epyrus source code directory.
23. Repeat steps 7 and 8, but in a GNOME terminal window instead of a Git Bash window obviously.
24. Type
vim .mozconfig, verifying that I have a 64-bit build and everything is correct.
25. Type
scl enable devtoolset-7 bash to use a newer version of GCC than what comes with CentOS 7.
26. Type
./mach build, and prepare for the build to take an unusually long time because my CentOS 7 VM can randomly be dog slow for unpredictable reasons... sometimes it builds in 20 or 30 minutes, sometimes it takes over an hour, and I never know which it will be.
27. Use
./mach run to verify everything is working.
28. Type
./mach package && ./mach mar to generate a tarball and an update MAR.
29. Finally, type
./mach updater-xml again to generate the update xml needed for Linux, entering the currently released version of Epyrus carefully and making sure not to enter the version I'm building.
30. Upload the Linux-based files, the update mar, the tarball, and the update xml to OneDrive so I can access it on Windows.
31. Open WinSCP on Windows.
32. Login to the Epyrus hosting provider with username and password.
33. Carefully navigate to where AUS looks for updates.
34. Create a new directory named for the version I'm about to release within the subdirectory associated with each platform, and make sure to put an empty update.xml file there as place holder, otherwise users will complain about weird pop-ups saying that updating failed.
35. Go into the directory named for the version that's currently released, and paste the update.xml and MAR file I generated for each platform into the correct folder, being careful not to mix things up and deliver the wrong bitness/OS to the wrong people.
36. While I'm at it, go ahead and upload the the new installers/tarballs/zip files of newer versions for download on my Downloads page, editing the HTML and making sure to update the link and remove the tarballs/installers of the older versions, avoiding the need for page formatting changes with each release or using up extraneous disk space on my hosting service by offering older releases.
36. Check the Windows 32-bit and 64-bit versions update correctly myself on my own machines to make sure they updated properly, and just watch the forums nervously for a couple hours to see if Linux users complain, since the Linux build is almost always correct due to it being a single build with no counterparts, and the process being very different compared with 64-bit and 32-bit Windows.
37. Announce the new release on the forums, and I'm done, hopefully for a few months... I don't enjoy this process at all because I really can't afford to make a mistake here, and I'm not the most detail-oriented person in the world. So I try to avoid updating Epyrus more often than necessary because... well, look at this list.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind