SoylentNews is people
SoylentNews
Google has updated a mobile framework that targets Android, iOS, and the in-development Google Fuchsia OS:
On Wednesday, Google's cross-platform mobile framework Flutter reached Preview Release 1, a designation that places the code somewhere between buggy beta and less buggy 1.0.
"The shift from beta to release preview signals our confidence in the stability and quality of what we have, and our focus on bug fixing and stabilization," said Google group product manager Tim Sneath in a blog post.
Introduced in May 2017, Flutter provides a way for Linux, macOS and Windows developers to create mobile apps in the Dart programming language that can run on Android, iOS or Google Fuchsia, an operating system that Google is working on.
Apps would be bundled with the Flutter engine:
Flutter is Google's second swing at a mobile SDK (the first being a little platform called "Android"). Flutter's claim to fame is that it's cross-platform—Flutter apps run on Android and iOS—and it's really fast. Flutter apps sidestep the app platforms of Android and iOS and instead run on the Flutter rendering engine (written in C++) and Flutter framework (written in Google's Dart language, just like Flutter apps). When it's time to ship a Flutter app off to Google's and Apple's respective app stores, the requisite Flutter engine code gets bundled up with the app code, and the Flutter SDK spits out Android and iOS versions of your single code base. Each version comes complete with built-in app themes for Android or iOS, so they still feel like native apps. Along with Android and iOS, Flutter is also the platform used for apps in Google's experimental Fuchsia OS.
Related: Google's New Non-Linux OS: Fuchsia
Google's Not-So-Secret New OS
Google Fuchsia UI Previewed
Google to Add Swift Language Support to Fuchsia OS
(Score: 2) by KritonK on Sunday June 24 2018, @04:24PM
In other words, a gamma version.
In my days, people would write code. While the code was a work in progress, any distribution would be an alpha version. When the program was feature complete and debugged as much as it could be debugged by the persons that wrote the code, testers would receive beta versions, to discover the real bugs. Occasionally, a gamma version would be produced, to discover even more bugs. After testing, version 1.0 would be released to the public, who would always find a few more bugs, leading to version 1.1, which would be the best version of the program ever, as the next versions would be ruined by feature creep. If a program was updated dramatically (e.g., new program engine or tons of new features), version 2.0 would be produced, with version 2.1 again being the best release of version 2.
These days, incomplete alpha versions are distributed as beta versions, and buggy beta versions are distributed as "release candidates", which they most certainly are not, as development roadmaps often indicate that more than one such release candidate is scheduled to be released. (E.g., LibreOffice usually schedules the release of RC1 and RC2 versions, which should really be called beta and gamma.) As for versioning, we usually get streams of three or more numbers, separated by dots, where often the only significant numbers are the two last, with the other numbers rarely, if ever changing (e.g., Linux 2.6.x.y) or changing arbitrarily (e.g., Linux 2.6.x.y→3.x.y or 3.x.y→4.x.y) without any real reason for a version bump other than aesthetics. We even get programs which are stuck at version 0.x.y forever, even though they are very stable and reliable. On my computer, e.g., more than 17% of installed packages are at version 0. I guess their version will be bumped to 1 only when the mythical last bug has been fixed.
My lawn is staying at version 1.1, so get off it!