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.  
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  
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  
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  
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. }
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/  
8. Breaking  Changes  in  Maven’s  90,000  Updates   8  
9. 9   Breaking   Changes  versus   Update  Type?  
10. Breaking  Changes  over  Time   10  
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
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  
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  
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  
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  
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  
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  
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