On Software Changes: Versioning in the Maven Ecosystem

Presentation held at the Symposium on the Future of Programming. January, 2014, Delft University of Technology, The Netherlands.

http://eelcovisser.org/wiki/future-of-programming

A video recording of the talk is available at:
https://collegerama.tudelft.nl/Mediasite/Play/7f7f321ea08d410e967f6465dd3bb0a61d?catalog=fd32fd35-6c99-466c-89d4-cd3c431bc8a4 (this presentation starts after 1h:07m).

Transcript

1. On  So&ware  Changes:   Versioning  in  the  Maven  ecosystem     Arie  van  Deursen     Joint  work  with   Steven  Raemaekers   Joost  Visser   1  
4. A  Coordinate  System  for     So&ware  EvoluEon   4   “Business  value”   “Agility”   v1   v2   v3   v4   v5  
6. Disciplined  development   6   Business  value   Agility   v1   v2  
7. Pure  Refactoring   7   Business  value   Agility   v1   v2  
8. Quick  and  Dirty   8   Business  value   Agility   v1   v2  
10. We  Need  to  Study   So&ware  Change   10   Requirements   DocumentaEon   Issue  Tracker   Test  Reports   What  can  we   learn  from   so&ware   repositories?   Time   Source  Control  
11. Change     Granularity   •  Edit   •  Commit   •  Bug  fix   •  Pull  request   •  User  visible  feature     •  Project  /  API  release   •  Product  delivery   11   flickr.com/photos/wackybadger/  
12. The  Maven  Dataset   •  150,000  released  jar  files   •  100,000  with  source   •  As  in  Maven  Central  on  July  30,  2011   •  With  resolved  usage  data   12  
13. Research  QuesEons   •  How  do  API  developers  deal  with  breaking   changes?   •  How  common  are  breaking  changes?   •  Do  version  numbers  help  to  esEmate  breaking   changes?   •  What  factors  affect  introducEon  of  breaking   changes?   13  
14. Breaking  Changes  in  APIs   14   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. }
15. Binary   Incompa-bili-es   Focus  of  study:   Removals:  Interface,  class,  method,  or  field   Changes:      Nr  of  parameters,  or  change  in                                            field  /  parameter  /  return  type   15   “Pre-­‐exis-ng  client  binaries  must  link  and  run  with  new  releases   of  the  component  without  recompiling.”  -­‐-­‐-­‐  the  CLIRR  tool.   flickr.com/photos/dullhunk/  
16. Public  Method  /  Class  Removals   in  8  versions  of  H2DB   16  
17. In  all  Maven’s  90,000  Update  Pairs:   17  
18. Is  Anything  Being  Broken?   •  Maven  libraries  depend  on  ...  each  other   – S  uses  L;     – L  updated  to  L’;   – Will  S  compile  with  L’?   •  Assess  impact  by  step  by  step    injec-on  of   breaking  changes   18   InjecEng  breaking  changes  leads  to  14,000,000   compile  errors  with  Maven  set  alone  
19. Does  Versioning  Help?   Major  .  Minor  .  Patch  in  SemVer   •  Major:  incremented  when     incompaEble  API  changes  are  made   •  Minor:  incremented  when  funcEonality  is   added  in  backward  compaEble  manner   •  Patch:  incremented  when     backward-­‐compaEble  bug  fixes  are  made   19   semver.org:  Based  on     “pre-­‐exis-ng  widespread  common  prac-ces”  
21. 21   What  about   breaking   changes?  
22. Breaking  Changes  over  Time   22  
23. DeprecaEon  to  the  Rescue!   “Depreca-ng  exis-ng  func-onality  is  a  normal   part  of  soAware  development  and  is  oAen   required”  (semver)     DeprecaEon  in  semanEc  versioning:   1.  Update  documentaEon   2.  Introduce  deprecaEon  in  minor  release   3.  A&er  that  remove  method  in  major  release   23  
24. DeprecaEon  to  the  Rescue?   Depreca<on  pa=ern   Frequency   %  Update  pairs     Delete  public  method   (no  deprecaEon)   86449   33%   Add  public  deprecaEon   (no  deleEon)   793     0.3%   Delete  deprecated  method   0   0%   24  
25. DeprecaEon  to  the  Rescue?   Depreca<on  pa=ern   Frequency   %  Update  pairs     Delete  public  method   (no  deprecaEon)   86449   33%   Add  public  deprecaEon   (no  deleEon)   793     0.3%   Delete  deprecated  method   0   0%   25  
26. Does  Size  Maoer?   26   0 2 4 6 8 10 log(#Breaking changes) 2 3 4 5 6 7 8 9 log(Number of methods)
27. Does  Age  Maoer?   •  Maturity  =  release  index  =   number  of  versions  of  library  unEl  now   •  Correlate  release  index  with  #  breaking   changes   •  More  mature  libraries  introduce  fewer   breaking  changes  (r  =  -­‐0.3,  p  =  0)   27  
28. When  Is  Impact  Dispersed?   28  
29. When  Is  Impact  Dispersed?   •  Dependent  variable:   – DisEnct  methods  with  error  due  to  update   •  Independent  variables:   – Age  (release  index)   – Size  (number  of  methods)   – Library  popularity  (usage  frequency  in  maven).   29  
30. When  Is  Impact  Dispersed?   30  
31. Discussion   •  Maven  data  set:  Very  rich  resource   •  A  breaking  API  is  a  fact  of  life   – DeprecaEon  is  not  adopted.   – Old  is  beoer   – Large  is  worse   •  Dispersion  affected  by  size,  age,  and   popularity   31  
32. Discussion   •  Is  Java’s  (lack  of)  modularizaEon  to  blame?   •  Maven  analyEcs   with  IDE  support?   •  Just  Maven  Central?   –  Commercial  (maven-­‐based)  systems   –  .NET  nuget,  Ruby  gems,  web  services   32  
33. Discussion   •  Beyond  syntacEc  incompaEbiliEes?   – Include  test  suites  in  analysis?   – Study  contracts,  LSP,  SOLID,  …   •  “Breaking  an  API  is  bad”,  versus   “cleaning  up  an  API  is  good”   33  
34. The  Future  of  Programming?   •  To  know  the  future,  we  must  see  the  past   •  We  are  incompaEble   •  Change  must  become  a  first-­‐class  ciEzen   34  
35. Further  Reading   •  Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser:   The  maven  repository  dataset  of  metrics,  changes,  and   dependencies.  MSR  2013:  221-­‐224   •  Steven  Raemaekers,  Gabriela  F.  Nane,  Arie  van   Deursen,  Joost  Visser:  TesEng  principles,  current   pracEces,  and  effects  of  change  localizaEon.  MSR   2013:  257-­‐266   •  Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser:   Measuring  so&ware  library  stability  through  historical   version  analysis.  ICSM  2012:  378-­‐387   35