$30 off During Our Annual Pro Sale. View Details »

Semantic Versioning Versus Breaking Changes

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

Arie van Deursen

September 29, 2014
Tweet

More Decks by Arie van Deursen

Other Decks in Programming

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. 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