I know it isn't black & white, but I think it's better portrayed that way rather than how it is portrayed now. I personally don't care if people have a newer version or not and I think that you and fravaccaro know the risks, but then I see bunch of other people who have no idea what they're doing (definitely the vocal ones in those threads) and they are going to ruin it for the rest. We've seen how mad had some people gotten over the tablet fiasco, so I can only imagine how would it be if more bricks occurred, those people turned to Jolla Care and naturally got told that it's not covered by the warranty.

The problem I have is with the threads portraying it as normal and as easy as 2-3 commands in the terminal.

For all you know, it is a random build, especially if you have the first Jolla. Let's list some facts:

• This release is essential for some of the functionality of the Intex Aquafish/Jolla C (dual SIM).
• The Intex phone has been quite delayed. Yes, it could be a problem on Intex's side, but since the software update hasn't been released yet, I think that Jolla is definitely to blame as well.
• The Intex partnership is crucial for Jolla and every delay on their side is hurting it.
• Jolla (1) is now 30 months old - it's great that we are still getting updates, but we can hardly expect it to be a priority for the company, especially in their financial situation.
• Guys who have installed the new release report newer hardware adaptation version for Jolla (1).
• I haven't seen any of the important bug reports (non-functioning sound recorder, bricked device, no alarm sound, screen wakeup being reported by the Jolla C owners.

I am pretty sure Jolla C/Aquafish was the target device for this release and the optimizations for Jolla (1) will follow, but it is not made for it and since there are changes needed in the hardware adaptation, bricks and other problems are more than likely.

EDIT: Here you go, my conclusion is spot on.

I can only speak for myself, but if I had an app on Github and someone built a version on OpenRepos after each of my commits and then people reported a dozen of issues after each of those commits, I would be pretty unhappy about the situation. Either way, it I could not tell people "don't report bugs", because I would not want to be rude and I would still appreciate more experienced eyes on my code. But like in other cases, 90% of the issues raised would likely come from people unfamiliar with the code or the difference between commits and releases, so I would probably stop commiting publicly which would be bad for me (no code overview) and for those who know how to build it and want to see new features while knowing it's not a final version.

Why would I stop?

1. I would not want regular people to have bad experience with my app - if I install an app and it works poorly, I don't give it a second chance very often.
2. If I tried to reply to all those bug reports, it would take me more time than coding.
3. If I did not reply to them, people would turn away and wouldn't report bugs once a real testing version is released.