Semantic Versioning Versus Breaking Changes

Steven Raemaekers, Arie van Deursen, Joost Visser.

Semantic Versioning versus Breaking Changes: A Study of the Maven Repository.

Presented at IEEE Working Conference on Source Code Analysis and Manipulation (SCAM), 29 September, 2014, Victoria, BC, Canada.

Preprint of paper available at http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2014-016.pdf

Transcript

1. Seman&c  Versioning    
   versus  Breaking  Changes:    
   A  Study  of  the  Maven  Repository  
   Steven  Raemaekers  (SIG,  ING)  
   Joost  Visser  (SIG)  
   Arie  van  Deursen  (TU  DelI)  
   1  
   Presented  at  IEEE  SCAM,  29  September  2014,  Victoria,  BC,  Canada.  
   

   View Slide

2. Seman&c  Versioning  
   Major  .  Minor  .  Patch:  
   •  Major:  incremented  when    
   incompa&ble  API  changes  are  made  
   •  Minor:  incremented  when  func&onality  is  
   added  in  backward  compa&ble  manner  
   •  Patch:  incremented  when    
   backward-­‐compa&ble  bug  fixes  are  made  
   2  
   “Based  on  pre-­‐exis.ng  widespread  common  prac.ces”  
   semver.org  
   

   View Slide

3. Research  Ques&ons  
   1.  To  what  extent  are  backward  compa&bility  
   constraints  of  semver  followed?  
   2.  Has  adherence  to  semver  increased  over  
   &me?  
   3.  Does  semver  conformance  speedup  upgrade  
   behavior?  
   4.  If  there  are  breaking  changes,  are  they  
   correctly  deprecated?  
   3  
   

   View Slide

4. The  Maven  Dataset  
   •  150,000  released  jar  files;  100,000  with  source  
   •  As  in  Maven  Central  on  July  30,  2011  
   •  With  resolved  usage  data  
   4  
   Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.  
   The  maven  repository  dataset  of  metrics,  changes,  and  dependencies.  MSR  2013:  221-­‐224  
   Julius  Davies,  Daniel  M.  German,  Michael  W.  Godfrey,  and  Abram  Hindle.    
   SoIware  Ber&llonage  -­‐  determining  the  provenance  of  soIware  development  ar&facts.  EMSE,  2013  
   

   View Slide

5. View Slide

6. Incompa&ble  API  Changes  
   6  
   1. // Version 1 of Lib1
   1. public class Lib1 {
   2. public void foo() {...}
   3. public int doStuff() {...}
   4. }
   1. // method2 uses foo & doStuff
   1. public class System1 {
   2. public void method2() {
   3. Lib1 c1 = new Lib1();
   4. c1.foo();
   5. int x = c1.doStuff();
   6. anUnrelatedChange();
   7. }}
   1. // Version 2 of Lib1
   1. public class Lib1 {
   2. public void foo(int bar) {...}
   3. public String doStuff() {...}
   4. }
   1. // method2 uses foo & doStuff
   1. public class System1 {
   2. public void method2() {
   3. Lib1 c1 = new Lib1();
   4. c1.foo();
   5. int x = c1.doStuff();
   6. }
   7. }
   

   View Slide

7. Our  proxy:    
   Binary  Incompa.bili.es  
   Focus  of  study:  
   Removals:  Interface,  class,  method,  or  field  
   Changes:      Nr  of  parameters,  or  change  in    
                                          field  /  parameter  /  return  type  
   7  
   “Pre-­‐exis.ng  client  binaries  must  link  and  run  with  new  releases  
   of  the  component  without  recompiling.”  -­‐-­‐-­‐  the  CLIRR  tool.  
   flickr.com/photos/dullhunk/  
   

   View Slide

8. Breaking  Changes  in  Maven’s  90,000  Updates  
   8  
   

   View Slide

9. 9  
   Breaking  
   Changes  versus  
   Update  Type?  
   

   View Slide

10. Breaking  Changes  over  Time  
    10  
    

    View Slide

11. Update  Lags  
    11  
    L1
    uses
    Jan 1 May 1
    Feb 1 Mar 1 Apr 1
    S1
    L2
    S2 S3
    next ver.
    L3
    Aug 1
    S3-L Update lag
    patch major minor
    One minor
    release lagging
    

    View Slide

12. Update  Lags  in  Maven  
    Correla&on  between  lag  and    
    number  of  breaking  changes?  
    Hardly:  0.14  for  minor  releases  
    0.02  and  0.08  for  patch  and  major  releases  
     
    12  
    

    View Slide

13. Depreca&on  to  the  Rescue!  
    “Depreca.ng  exis.ng  func.onality  is  a  normal  
    part  of  so@ware  development  and  is  o@en  
    required”  (semver)  
     
    Depreca&on  in  seman&c  versioning:  
    1.  Update  documenta&on  
    2.  Introduce  depreca&on  in  minor  release  
    3.  AIer  that  remove  method  in  major  release  
    13  
    

    View Slide

14. Depreca&on  to  the  Rescue?  
    Depreca9on  pa:ern   Frequency   %  Update  pairs  
     
    Delete  public  method  
    (no  depreca&on)  
    86449   33.0%  
    Add  public  depreca&on  
    (no  dele&on)  
    793  
     
    0.3%  
    Delete  deprecated  method   0   0.0%  
    14  
    

    View Slide

15. Depreca&on  to  the  Rescue?  
    Depreca9on  pa:ern   Frequency   %  Update  pairs  
     
    Delete  public  method  
    (no  depreca&on)  
    86449   33.0%  
    Add  public  depreca&on  
    (no  dele&on)  
    793  
     
    0.3%  
    Delete  deprecated  method   0   0.0%  
    15  
    

    View Slide

16. Discussion  
    •  Does  communica&ng  backward  compa&bili&es  
    through  version  numbers  maler?  
    •  Usage  of  broken  func&onality?  
    •  Is  Java  modulariza&on  to  blame?  
    •  Beyond  maven:  npm,  nuget,  OSGi,  Ruby  gems?  
    16  
    

    View Slide

17. Summary  
    •  One  in  three  API  releases  includes  breaking  
    changes  
    •  One  in  four  version  numbers  does  not  signal  
    breaking  changes  correctly  
    •  Depreca&on  does  not  help  
    17  
    

    View Slide

18. Paper  
    Steven  Raemaekers,  Arie  
    van  Deursen,  Joost  Visser  
    Seman&c  Versioning  
    versus  Breaking  Changes:  
    A  Study  of  the  Maven  
    Repository.  
    Proc.  Source  Code  
    Analysis  and  Manipula&on  
    (SCAM),  IEEE,  2014  
    18  
    

    View Slide