简体   繁体   中英

How to measure software component maturity by processing version numbers?

I'm trying to implement a metric that describes how mature/stable a software component is by looking at how many versions have been made of it in a certain time frame (or from a starting date).

More versions would indicate a less mature/stable component. But this would not be accurate: when looking at a larger time frame, a component might've had many changes at the beginning, but very few recently. This indicates a stable component. Also, version numbering should probably be factored in. A change from '1.4' to '2.0' should be more significant than a change from '1.4.1' to '1.4.2'.

In a nutshell: older changes should matter less, higher increase in version number should matter more.

Is there an industry standard weight function that would achieve the desired result according to these criteria? Or should I attempt to create my own?

Have a look at Semantic Versioning :

Given a version number MAJOR.MINOR.PATCH, increment the:  

MAJOR version when you make incompatible API changes,  
MINOR version when you add functionality in a backwards-compatible manner, and  
PATCH version when you make backwards-compatible bug fixes.  
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

In addition, I use a fourth number REVISION which is the SVN revision of the build package created from the source code at that revision. I update the assembly versions of my components with this number during the build, eg:

2.0.3.xyz

Hope this helps.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM