What is "a, b and RC"?

Readers can download this issue in PDF format here. There are some slight and interesting differences.

==//==

Author: Howard Wu
Date: March 7, 2022

A common and simple notation used for software delivery is the “a, b and RC” method. This is more common in software like operating systems and stable B2B product lines. But it's still a good representation for specifying the versions by showing how ripe your product is among team members in different time zones and locations.

Introduction for the universal notations

In software development, it is important to mark your stages of development and let other developers, early testers know where we are now.

• A stands for “alpha”, there are 100 versions in this phase.
• B stands for “beta”, there are 10 versions in beta.
• RC stands for “Release Candidate”. There are 3 versions of this.

Have you noticed that the “EP” tag is not mentioned? EP is a status that is specifically designed for Emergency Patch. It is not part of software development, but it is a really common part of software development reality when bugs are found after deployment.

 

In this case, the next version of Firefox 98.0-b9 is going to be b10. The next version after b10 would be 98.0-RC1, then the official stable 98.0. Smaller features or bug fixes will be rolled out in the next few minor versions such as 98.1, 98.2, 98.3, etc.
After that, a new dev cycle for 99 alpha, beta, RC will start all over again.

The timeline and respective events (meetings) for each functional team would look like this:

1. Developers work on Local env, and ask for DBA or devops to provide dev env for daily build env.
1. PjM creates tickets by
2. PdM sorts tickets and picks the most common ones as the features for this version
3. All requirement changes must be logged in tickets so all participants can watch the changes without one to one notification. This is the key to team success.
   
4. Developers have more coordination with PjM
2. New features are being evaluated. This is the time to decide what could possibly be done in this release.
1. No need to report every change to team members, just report to your own project tickets.
2. Developers will have more communication with PdM
3. Crazy things and unexpected bugs, integration errors are everywhere. This is the time to decide what can be done in this sprint.
4. "Done" tickets are collected for writing documentation.
5. Developers should provide swagger to technical writers so that they can start working on details and writing documentation.
1. If anything is changed in this stage, reasons must be specified on tickets. QA and technical writers must be notified.
2. Technical writers should work closely with QA, PdM, developers at this stage. Documentation and release notes are being consolidated and it would take 7 days at least. If everything's working right, Documentation is aligning with the done and picked tickets, not the actual behavior of the program.
3. QA is responsible for the functionality verification in the tickets.
4. PdM and PjM are responsible for “not changing anything” in this stage. Requests can only be reduced or postponed. Exercise all your skills to soothe customers, do not irritate them or fall into the sinkholes of over promise.
5. Greedy customers often cook up new demands at this stage, PdM (PO) must stop them right at the spot — with the tickets we had analyzed as strong evidence, and show them the contract we signed. Do not oppress your poor fellow coworkers with the meteor fall methodology.
6. PdM + PjM = PO
6. A final review meeting for finished documentation (4 days before launch).
1. Finished documentation is being reviewed by PdM and developers at this stage.
2. PdM or PO reserves the right to correct anything in documentation.
7. A pre-deployment meeting will be held by PjM two days before the services go live ( Stage -> prod).
8. EP usually only max to EP 4 then an EoS (end of support) will be announced.
1. Announcement for api deprecation is very similar to EoS. You don't deprecate your PaaS api within a week. You can't change your api schema 4 times every month without prior notification or good reasons. 
2. Check for our earlier post on api RoC (Rate of Change) calculation.
   

The product timeline (Software release life cycle)

 

This timeline shown below only serves as an example for better team communication. This is a typical software release life cycle, described in a product manager (PdM) way. It fits for all methodologies, such as waterfall, agile and scrum.

 

You’re welcome to add your opinion and we will select what’s best fit in our next issue!  If your teams have any questions regarding necessary FAQ or guidelines for your software and products delivery, please contact me and I will see what I can do to help you with your service documentation. This can mitigate your pain of daily IM (instant message) bombing from team members and customers.

Next issue: “How and why you should report status to your projects (issue tracker), not your project managers.”

 

Are you getting confused by PjM, PdM, PO terms in this post?  Their functional definitions will be introduced in the next issue. Interested in earlier issues? Check them our blog section.

Reference

1. Software release life cycle - Wikipedia
2. PEP 440 -- Version Identification and Dependency Specification | Python.org

Submit your articles

This is the bi-weekly issue for technical writing, software development, and product management. You are welcome to express your opinion or submit your thoughts to our email.

I will select the most relevant ones for publishing.