Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A small suggestion regarding the release process #1765

Open
beastie1 opened this issue Apr 11, 2024 · 5 comments
Open

A small suggestion regarding the release process #1765

beastie1 opened this issue Apr 11, 2024 · 5 comments

Comments

@beastie1
Copy link
Contributor

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.

@Emdek
Copy link
Member

Emdek commented Apr 14, 2024

@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.

@Frenzie
Copy link
Member

Frenzie commented Apr 14, 2024

#1685 for reference

Iirc it was looking pretty good but it might need to be updated a bit.

@beastie1
Copy link
Contributor Author

beastie1 commented Apr 14, 2024 via email

@Emdek
Copy link
Member

Emdek commented Apr 15, 2024

@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.

@beastie1
Copy link
Contributor Author

beastie1 commented Apr 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants