[not a question] discussion about strategy of release making

asked 2018-06-10 20:35:52 +0300

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2018-06-10 20:57:39 +0300

cemoi71 gravatar image

Hello Sailors,

after the last release and heavy discussion.

I open now a discussion about the strategy of release of software.
I don't want to put oil on fire, whether criticize negatively what the dev team and manager has done.

But remarks and critique (positive) should be done.
It gives me the possibility to explain my misunderstanding about the jolla-man release-in-charge strategy.

If i remember by last releases was some functionalities as not release versions, but beta or alpha brought inside.
I think about (pretty fast i admit it) vpn-tunnel, and shortly emoji-keyboard...

A release For me, is a part is enough well tested, that all bug and unintended reactions put aside.
Means all the "collection of functionality" have a stable stand and are as "release" noticed, with a release version.
A beta & alpha could not be arranged inside. If the need is to put inside, then all the functionality should be reduced to its stable form.
Otherwise, then push it on the software-market as beta/alpha.

for an os release version, wording like beta and alpha are not adapted.
If already reduced to a stable, but hasn't the full functions (like i suspect for the emoji keyboard).
Then it could be taken as release, with v1, with a mention that later comes further functions.

Thus that was my short point of you of a release strategy, with my misunderstanding on the one of the sfos. A little bit missy. but that's start point for having other point of view from other.
i'll be glad if it could help to give a constructive direction to the development of the os.

Have a good sail

edit retag flag offensive close delete

Comments

Jolla & Sailfish OS, in spite of the bugs or versions that may be insufficiently tested, I remain convinced that Jolla is still one of the alternatives most relevant to the market. Not to say the only and the most relevant. Because of this, I am ready to accept the bugs because it is not a question for me to go back to solutions "mainstream" market. For me, the main flaw, these are not the bugs but the eco system around Sailfish OS that is not growing strong enough and as fast as I would like. For the bugs, thanks to the community TJC: we always find a solution or a workaround ;-)

mips_tux ( 2018-06-11 10:56:37 +0300 )edit

@mips_tux that's not the question. for me too it is the only one alternative. i don't want to destroy the system or injure the dev team.
At last it will be always something like a bug.
But i think that not constructive to accept intended bugs.
I'm for a cosntructive way to improve the process
I don't want to close my eyes before a known leak or a fresh found one.
Accept a leak by xlosing our eye may be fatal. and that's not pretty in development process.
A released software should have all is small software parts as released to. otherwise is not a release, but have the weaker denomination (alpha if a weak part is alpha).
that belong for me to the health of the process.

cemoi71 ( 2018-06-11 16:46:33 +0300 )edit