-
Notifications
You must be signed in to change notification settings - Fork 275
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
Comments
@beastie1, there is one big issue, manpower… |
#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.
The text was updated successfully, but these errors were encountered: