How Stable Is Stable Enough?

You are reading "Goobar," an Android development newsletter exploring the latest tools, tips, and trends from the world of Android. We're dedicated to helping you learn and grow in your career as an Android developer, so if you like what you see, be sure to subscribe.

Welcome devs ??

Several times, over this past week, I found myself coming across release announcements for Android libraries that I’ve been interested in.  In particular, I was pleased to see releases for WorkManager, Navigation, and MDC-Android:

• WorkManager Version 2.3.0-beta02
• Navigation Version 2.2.0-rc04
• Material Components for Android 1.2.0-alpha03
• Material Components for Android 1.1.0-rc01

Honestly, I find even this short list of 4 releases to be plenty to try and keep track of.  It wasn’t until I sat down to write this article that I realized that, in this past week, there were nearly 20 library releases coming from Google alone.

That’s a lot of information to follow and process.

As these updates kept popping up throughout the week, two questions were floating around my mind:

1. How do we keep track of important library updates?
2. How stable does a library have to be to consider using it in a production app?

How do you keep track of important library updates?

With so many updates being rolled out from Google alone, how do you keep track of these releases, their new functionality, and bugs; both old and new?

For AndroidX Updates

For Google libraries under the androidx umbrella, there is thankfully a complete list of release notes available which is updated regularly.  Here, we can find which libraries have been updated recently, and examine the release notes for any we are particularly interested in.

Additionally, Google has thankfully made it easy to separate out release updates by their stability: Stable, RC, Beta, and Alpha.

Or, we can navigate directly to the release notes for a particular androidx library such as Fragment, RecyclerView, or ViewPager2.

For Other Libraries

A single location for all the androidx artifacts is great, but what about for other tools and libraries we want to follow?  How do we keep track of these changes?

This is a tougher question maybe, and If you have ideas or resources for this, I’d love to hear about them in the comments.

For many tools that are built in the open via GitHub, GitLab, etc, there is generally some type of star or watch mechanism that allows us to be notified of updates regarding a particular tool.  So, if you find a library on GitHub for example, and want to know when a new release is created, you could watch that repo to receive an update, or simply star the repo and remember to check back periodically.

Another channel I’ve found to be pretty effective, is following companies/teams/developers on Twitter.  With the increase in devrel efforts for many companies, it’s possible to discover tool and library updates via social media.  Honestly, this is how I discover many of these updates; as I did this week for MDC-Android updates.

Relying on social media posts is certainly not the most “scientific” approach, but if you’re already active on Twitter, you might be able to naturally come across these updates throughout your regularly scheduled scrolling.  To help get you started, you can subscribe to this Android DevRel list on Twitter maintained by Walmyr Carvalho.

You can’t learn it all

I want to make one last point here; especially for those that are new to software development or Android specifically.

Notice I’ve been saying “keep track” rather than “stay up to date.”  This was very deliberate, as I don’t think it’s possible to truly stay “up to date” on all things Android any more.  There were nearly 20 library updates from Google alone on December 18. That’s too much to discover, explore, and digest.

With this in mind, I encourage you to not put too much pressure on yourself to keep track of all these libraries, tools, and updates.  A more sustainable strategy is to discover and follow these things as you need them, and then maybe check back once in a while to see what’s new.

How stable is stable enough to consider using a library in production?

Now, I want to revisit that list of 4 library updates I included at the beginning of this article:

• WorkManager Version 2.3.0-beta02
• Navigation Version 2.2.0-rc04
• Material Components for Android 1.2.0-alpha03
• Material Components for Android 1.1.0-rc01

Notice anything about this list?

None of these releases are stable.  If we look at the full set of androidx updates from December 18 we’ll find that less than ? of the updates are considered stable.

As I was thinking about this, it begged the question “How stable is stable enough?”

Google has a pretty clear stance on how they view the production-readiness of their various stability levels.

• Alpha - Alpha releases are functionally stable, but may not be feature-complete.
• Beta - They are ready for production use but may contain bugs.
• RC - A release candidate is a prospective stable release.
• Stable - These are, well, stable and ready for production

While Google clearly believes that developers should feel comfortable using at least beta, rc, and stable versions of a library, it’s always felt to me that many orgs and teams don't feel the same.

I’ve personally been on teams which had a pretty strict “stable only” policy, and I’ve been on teams where we had the freedom to try, and get burned by, alpha releases.

To try and get some sense of the Android developer community’s opinion on this, I posed the question on social media to see what others had to say.  The general consensus seems to be “stable only” for many teams, and beyond that some were okay using beta releases

If you want to view the discussion/results for yourself, you can find them on Twitter, LinkedIn, and Instagram.

The notion that most teams would only allow stable or beta isn’t really that surprising, but it does present a potential challenge.  What does your team do when a library has frequent beta updates, but infrequent stable releases?

A good example of this are the Material Design Components for Android.  This is a library I know a lot of developers, myself included, have been excited about.  However, it’s been over a year since the last stable release. In the meantime, many alpha and beta updates have added additional components and functionality.

If your team strictly enforces a “stable only” policy, you might be out of luck in a situation like this.

Should “stable only” be relaxed for certain developers?

In the case of Google, or other proven companies like Square, I wonder if organizations are doing themselves a disservice by strictly adhering to the “stable only” policy?

Should Google change their stance on “production ready beta” releases?

On the other hand, if Google’s policy is that a library is production ready once it hits the beta channel, couldn’t that library then be considered “stable enough” to promote to the stable channel, thereby empowering more teams/developers to start using it?

How do you evaluate the production-readiness of a third party library?

I personally think there’s not a one-size-fits-all solution to these questions.  Unless all developers unite to adopt a single interpretation of what it means to be “production ready” we will always have to make our own evaluations before adopting a new library.

Now, if you’re new to software development, this type of evaluation might be a bit confusing or overwhelming.  That’s completely fair since any project/dev/team/org is going to have different considerations to keep in mind and different levels of acceptable risk when adopting a new tool or library.

To help guide you in the right direction, here are a few things for you to consider before adopting a new library or version update:

• How many users will receive the updated version?  If you have 0 users, there’s not much risk involved if the library breaks something.
• Who is developing the library?  Trusted developers like Google or Square are likely to have a high quality bar, and it might therefore be less risky to adopt a beta version.
• Is the library open source?  If you adopt a library which you can fix and extend on your own, then the overall risk in adoption may be decreased.  However, not all developers or teams have the bandwidth to fix open source code. So, keep in mind how much time and energy you, or your team, can devote to maintaining an adopted tool.
• Is the library solving a real problem?  If a version update isn’t adding any new functionality, or fixing a critical bug, then how much value is it adding to your project?  Is the risk of introducing new bugs less than the value added?

Before you bump those version numbers, take a minute to think critically about whether or not a version update is really worth it.  For some things, that might mean a “stable only” policy, while for others, the benefits of a beta release might outweigh any perceived risk.

Do you use -alpha, -beta, or stable only library versions?

As with many things, the answer to the question “How stable is stable enough” is likely “It depends.”  

However, I will give one last piece of opinionated advice learned from personal experience: avoid alpha releases in production unless you have a thorough testing and QA plan in place.  

Trust me.

What in the world of Android development are you interested in right now? Join in the conversation in the comments below.

See you next time devs ??