Open beastie1 opened 7 months ago
@beastie1, there is one big issue, manpower… What you suggest used to be handled by weeklies (but hey didn't have tags), but currently all of my build pipelines are more or less broken (except of the one used for producing packages compatible with Windows XP)… There was some work on using Github Actions to produce builds, but AFAIK it is not usable yet.
https://github.com/OtterBrowser/otter-browser/pull/1685 for reference
Iirc it was looking pretty good but it might need to be updated a bit.
It's certainly not my intention to give you more work. All I'm asking for is a tag for monthly or so "development releases". The burden would fall solely on the package building farms of the various Linux/BSD projects and distributions.
@beastie1, I'm not sure about tagging these, I think that it would be the best to revive weekly builds and start thinking about some alpha releases for 1.1.x. That would mean having builds even more often.
Would these weekly builds have tags? That's the crux of the matter. Weekly builds are great if you're on Windows. For anything else, people are stuck with official releases... unless there's a tag available. That way, distros can track development releases (or weekly releases if you will), and have the distros' own infrastructure build the package for them. It's a decentralized solution that's beneficial to the Otter project.
I can see issue #1762 for example on OpenSUSE concerning release 1.0.03. There's a similar issue on FreeBSD. It makes Otter crash after just a few seconds of use in some cases, a few minutes at best. That's the only option for most users on these systems. With just more frequent tagging, the problem solves itself within days or weeks at most.
I'd like to make a suggestion regarding the release process if I may. Quite often bugs end up creeping in when a release is made, and I think this may negatively impact the project's favorability ratings in the long run. Not everyone wants to track the latest source, build it and check if it fixes the problem. Not everyone has the time, patience or willingness to do that. And despite it being advertised on the website, not everyone knows it's even a thing they can do. So you end up with potential users abandoning the project from the get-do. They're shopping around for a browser, they check out what's available in their OS package repo, they try Otter, stumble upon some nasty bug and move on to another browser never to be seen again. So what I suggest is to make a new branch of "dev" releases every month, let's say. Since they'd just be "dev" release and not "official" releases, you won't need to provide official packages for every OS. Simply add a new tag and let the various Linux distros and *BSD family OSes build their own packages. This will greatly improve the rollout of new "releases" and will avoid the problem of being stuck with a problematic official release for a year or so.