Dependency behaviour of Haskell librariesAn extension to usage and switch-back tendencies in a different project environment

Marc Juchli, Lars Krombeen, Shashank Rao and Chak Shun YuDelft University of Technology

Abstract

Software developers face an enormous issue ofupgrading or downgrading their library versions as thecost of migration is huge and can result in introductionof bugs into the project. In addition to the previouslyobtained Java usage trends, our research aims atstudying the usage trends of Haskell libraries anddetermine if the popularity of a library is dependenton the programming language. We then extend ouranalysis to study the reason behind switching of differ-ent libraries by the developers. By analysing commitmessages, we categorise upgrades and downgrades oflibrary versions. Consequently, our research providesa technique to indicate which library version to use ina software project.

Keywords

datamining, library usage trends, version, API,switchbacks.

1. Introduction

Choosing which software library to use for yourproject is problematic for every programming team.Even when this decision has been made, it is still nottrivial what version should be used [1], [2]. Newerversions of software libraries tend to introduce newfunctionality, which oftentimes is the main reason forusing a library. It is also likely that an importantsecurity leak is fixed and therefore a new version willbe released. But what if, after integrating the newerversion into the project, an unforeseen bug occursand the developers want to switch back. Thus, dif-ferent choices for switching between newer and olderversions of libraries can prove to be quite difficult.

Therefore, Mileva et al. investigated the usage trendsof libraries among 250 APACHE Java projects thatintegrated MAVEN as their project management tool.They illustrate how these projects switched betweenlibrary versions and constructed a technique that isbased on the popular vote of the majority, the socalled wisdom of the crowd. Further more, they providenumbers for the usage of versions of libraries and forthe percentage of projects that switch between versionsof libraries. For the developers of those libraries, thisis valuable feedback as it gives insight about whichversions of their work are highly appreciated and used,and which are less.

Given the trend of popularity for Java projects,it is uncertain whether the same results hold forprojects written in other programming languages suchas Haskell. In this paper we take upon this uncertaintyand investigate whether the same result holds fordifferent project environments. By looking at usagetrends of other languages and comparing the resultswith the insight obtained by Mileva et al., we aim tomake a more general statement about popularity.

In addition to the study of version usage trends,we also expand on the reasons why developers decideto switch from libraries. Mileva et al. did provide rea-soning on why trends in library usages were observed,but they did not make this an actual part of theirresearch to cover all of the projects. In this paper,we will try to cover these reasons more in depth bycategorising switches between versions. Therefore weproceed keyword extraction and text analysis of thecommit messages.

Combining the two gained insights, version pop-ularity and the reasoning of version switches, ourresearch shall assist users in understanding the reasonbehind popularity in certain versions of libraries. Thus,we want to support the users in finding the mostsuitable library version for their projects, instead of

blindly following the majority.

The structure of this paper is as follows: First wewill describe the problem that we tackle in our research(Section 2). Then, we will provide background relevantto the problem that we defined (Section 3). Thiswill consist of a information about the research ofMileva et al. and a short description about Hackage.Thereafter, we will describe in detail the approach weused to collect the data necessary for answering ourresearch questions (Section 4). The approaches will bedescribed separately for both research questions thatwe use to solve the problem defined. After formallyformulating our research questions in Section 4, wewill show the results of our research and provideanalysis for their interpretation in sections 5, 6 and7. Finally, we will evaluate our research and reflectupon parts that could be improved and limitations inour research in Section 8.

2. Problem Definition

The problem that we address in this paper is thatit is problematic to choose proper library versionsfor your project and when to change the version ofthe library. When a new version of a used library islaunched it can be considered to change to the newerversion because the newer version fixes issues in thecurrent one, or you could decide to stick with thecurrent version because you do not require the updatesince everything is working fine. Another decision youcould make is to wait a period of time to make surethere are no issues with the library based on otherusers. Looking at usage trends can give library users arecommendation which version to use or avoid whichwill speed up decision making and prevents possibleissues with library that are used speeding up thedevelopment process. We also target to find out whylibraries are abandoned or why newer versions are notused. This can help library developers by improvingtheir application. For example, if a lot of users switchback from a certain version due to a bug, the librarydevelopers can quickly address the problem.

Consider that your company is building an applica-tion and wants to use a library for the image processingfor an arbitrary reason. But which one should youuse? Would you take the latest stable release or thelatest release which could contain bugs but introduceda functionality that could come in handy? Additionally,consider that you just released V2.1.0 of your library,but it is not used a lot. Instead, people stick with V2.0.7

which is the previous release. What could be the reasonbehind it? Is there a bug that you are unaware of. Arethe new features not as appealing as you originallythought. And what should you focus on for the nextrelease to make sure that it will be used?

3. Background

This section will discuss work that has previouslybeen done in the same research field with regardsto library usage and version switches. In addition,Hackage and Cabal, two important tools to an arbitraryHaskell programmer, are mentioned.

3.1. Previous work

Mileva et al. is a previous study done in 2009 thatwas in the same research field [1]. They tried to providea solution for choosing a specific library version basedon usage trends. This was done by mining hundreds ofApache projects to determine global trends in libraryusage. With the information a developer could fasterand easier determine which library version to use,speeding up the development process.

By looking at the pom.xml files within theseprojects they could gather information when a libraryversion was changed or abandoned. Given the changeand the date they could gather information about whichlibrary version was used and how many times it wasused at a given time stamp. This could easily beconverted to a usage trend.

3.2. Cabal

Cabal is a system used for the programming lan-guage Haskell to build and package libraries andprograms1. The Cabal can be used in projects to makesure that the developers have the same libraries anddependencies installed on their system.

3.3. Hackage

Hackage is Haskells community’s central packagearchive2. It contains various information about projects

1. https://www.haskell.org/cabal/2. https://hackage.haskell.org/

such as the published versions, the amount of down-loads, the dependencies of other libraries for everypublished version etc.

Hackage is typically used for authors to publishtheir software as packages, ready to be used in otherproject as dependency. It is also used for other Haskellprogrammers as a central place for library documenta-tion/usage.

4. Approach

The goal of the research was to find out if theresearch performed by Mileva et al. on library us-age trends for Java-based software projects hold forHaskell. We also went a step further and looked whypeople choose to switch versions or abandon a library.The research questions we would like to solve usingthe approach described in this section are as follows:

• Research Question1: How do usage trends of APIsin other programming languages compare to those inJava?• Research Question2: What are the reasons that

software developers switch between different librariesand versions?

4.1. Popularity of libraries in arbitrary pro-gramming languages

Given this trend of popularity for Java projectsdescribed by Mileva et al., it is uncertain whetherthe same results hold for projects written in otherlanguages. In order to investigate this, we will extractversion changes from our gained results in form oflibrary usage. The term usage in this case refers tothe situation when a software library is used by anothersoftware project.

Usage: library is considered as a dependency inexternal software project.

Thus, each time the library is used as a dependency,the usage increases by one. In a second step, weconfront the number of times a switch-back arisesto the amount of switch-back’s given in a MAVENbased project. Hereby, a switch-back arises when asoftware project depends on an older version of alibrary, whereas in a previous release a newer versionwas already used.

Switch-Back: dependent version was decreasedover time by an external software project.

In order to proceed this investigation, it is certainlybeneficial to rely as closely as possible to the sameapproach of analysing library usage as Mileva et al.However, as we have chosen to confront the resultswith those of another programming language, namelyHaskell, the process towards finding the final resultsmight be different from the paper we defined asour suspect of investigation. Nevertheless, once ourfindings in usages and switch-backs are prepared, weare positive that those can be compared to the onesfrom from Mileva et al. Consequently, we can providea statement in regards to whether it is or is not a wisechoice of which library version should be used, basedon usage trends.

The following part of this section will explain indetail the approaches we followed in order to collectthe which was data required to answer the first researchquestion.

4.1.1. Data Collection.

Selecting most used librariesHackage provides public insight into the topdownloaded (in the past 30 days) Haskell projects.We found this a valid starting point for collect-ing library information that is significant to anarbitrary Haskell user. As we describe in Section5, this hypothesis was confirmed with a snapshotcontaining all library downloads since Hackagewas launched in 2007. As a result of this firststep, a list of library names is available:

[ L i b r a r y ]

Mine versionsFortunately, the content of Hackage is storedin a Git repository3, which makes it handy todetermine the available versions of the mentionedlibraries in the previous step. Using Python as ourlanguage for the data mining tasks in the project,the second element of the function walk from theos library provides the names of elements withina folder. In this case, the elements are sub-foldersnamed after the version numbers available for theparticular library. As a results, we have now a listof libraries with all their released versions for thetime being:

[ L i b r a r y [ V e r s i o n ] ]

3. https://github.com/commercialhaskell/all-cabal-files

Publication dateAs the single source of a publication date for alibrary we could find was on Hackage itself. Wewere, at this point, forced to scrape the websiteof Hackage. Fortunately, every package, defininga specific library and version, holds its own APIendpoint on the Hackage website:

/ package / : package /

Therefore, an XPath (XML Path Language) querywas used to identify the location of the publicationdate stated on the website and thus, read itsvalue. After this step, a list of libraries with theirversions and publication dates was available to us:

[ L i b r a r y [ ( Vers ion , P u b l i s h e d ) ] ]

Resolve dependenciesThis step is critical, as dependencies are the rele-vant suspects of our investigation. Since Hackageprovides a distinctive website for the dependen-cies of a package, it was convenient to continuewith the approach of using XPath. Thus, forevery version above all libraries, we scraped thedependencies using the following API:

/ package / : package / d e p e n d e n c i e s

Finally, the data set contained all the informationfor proceeding with the analysis part:

[ L i b r a r y [ ( Vers ion , P u b l i s h e d ,[ Dependency ] ) ] ]

The important aspect at this point, in order tounderstand the data, is that a dependency isnothing else than yet again a library and versiondescription. In this case, one could describe theavailable data as follows:

[ L i b r a r y [ ( Vers ion , P u b l i s h e d ,[ ( L i b r a r y , V e r s i o n ) ] ) ] ]

4.1.2. Determine Usage. Usage information is not yetprocessed, but as stated in the paragraph above, all therequired data is given at this point. What is left to do,is to find the common dependencies above all librariesand their versions. It is convenient to represent thisinformation in a dictionary with the library and versiontuple as a key and the number of usages on a certaindate as value, again stored as a dictionary:

{ ( L i b r a r y , V e r s i o n ) :{ Date : I n t e g e r } }

Using an iterative approach, we looped throughthrough every library, its versions and their dependen-cies (see structure in paragraph above) and incrementedthe integer value by one for each occurrence of alibrary version tuple. As we know the publicationdate of the library-version using the library-version ofsuspect as a dependency, it is possible to mark the datewhen the usage happened. Eventually, this dictionaryrepresented the usage of all available library versions,including a very significant information, the date ofthat usage.

4.1.3. Determine Switch-backs. A switch-back wasdefined as the decrease of a version of a particulardependency. Decreasing a dependency version is onepossible outcome of a developers decision in regards todependency changes. The following are all the possibleactions a developer of a library is in control of, inregards to the previous version/release of the projecthe is working on:

• New: A dependency, which was not used in theprevious release, was added.• Switch-back / Downgrade: Resolved version ofdependency is older than the version used in theprevious release.• Upgrade: Resolved version of the dependencyis greater than the version used in the previousrelease.• Stay: Resolved version is equal to the versionbeing used in the previous release.• Remove: A dependency which was used in pre-vious release was removed.

The last three items of this list lead us to theconclusion that the implementation of a comparatormight be suitable function to indicate which case istrue, given two dependency versions. In order to definesuch a comparator, the following functionality must begiven. First, one must be able to parse the versiondefinition and second, one must be able to resolvethe absolute version being used given the versiondefinition.

Version definition parserParsing is very much bound to the specification of aversion definition in cabal4:

pkgname >= n

pkgname >= n && < m

pkgname == n.

*

Thus, we defined three corresponding classes, each ofwhich can take the version numbers as its arguments.

4. http://pvp.haskell.org

Tokenization of the version numbers is not requiredas Python can compare versions given as string

correctly by default. Given a version definition, theparser would then return the appropriate class.

GT(n)

GETandLT(n, m)

EQ(n, wc)

A possible wild-card post-fix for EQ definitions areindicated with a Boolean argument.

Resolve absolute version based on version definitionAfter it is known what type of version definition we areobserving (GT,GETandLT or EQ), the next step willlead to resolving the absolute version this definitioncorresponds to. This is no trivial task, as a versiondefinition in cabal may not relate to an absolute versionnumber directly. In fact, most of the version definitionfound in projects uploaded to Hackage contain eitherversion ranges (GT, GETandLT) or a wild-card withinthe EQ definition. At this point, one can follow twopossible approaches.Firstly, one could reconstruct the version resolving pro-cess as it must have happened back in time. Therefore,the publication date of the release of the library itsparticular dependency we are investigating serves asthe due date for the version definition. For example, iflibrary A-1.0 was release on date T and depends onlibrary B with version definition D (e.g. B >= 1 &&< 2), one would look up our available data from 4.1.1and see which was the latest possible version publishedat date T. However, this approach has one significantdraw back as it is not clear whether the developer didor did not decide on its own to proceed an upgrade,given the version definition was not changed. Thus, aversion upgrade would be counted much more oftenthan probably decided by a developers in the past.The second approach, a much more naive one, worksas follows. Given a version definition D, the absolutecorresponding version wont be resolved at all. Instead,one relies completely on the version definition – in aslightly modified way. For the EQ version definitionwild-cards wil be neglected, and for GETandLT, weonly consider the m of the definition. Thus, the resolvercan be described as follows:

GT(n) ! n

GETandLT(n, m) ! m

EQ(n, wc) ! n

Our results are based on the second approach due toits simplicity and the mentioned draw-backs of thefirst approach. However, a more accurate approachwould be a combination of both as mentioned inSection 8.

Defining the comparatorLast but not least we can define the comparator veryeasily give the functionality described above:

def compare(a, b):

av = parseVersionDefinition(a)

bv = parseVersionDefinition(b)

if resolveVersionNaive(av)

> resolveVersionNaive(bv):

return 1

elif resolveVersionNaive(av)

< resolveVersionNaive(bv):

return -1

else:

return 0

First, we parse both version definitions a and b. Thenwe resolve the absolute versions in a naive way beforewe compare those with each other.

Gaining insights into switch-back behaviourGiven the version comparator as a tool which can beapplied to the data we collected earlier (Section 4.1.1)will finally give insight into the upgrade- and down-grade behaviour of the Haskell libraries. Observingthe behaviour of upgrades and respectively downgradescan be done in two different ways, each of providinga slightly different insight. The first approach, whichis also described in Mileva et al., explains how oftena library, used as a dependency, was downgraded byother libraries. In the paper mentioned, as well as inthis paper, we call this behaviour switch-back. As aresult, we can produce, for an arbitrary library we areinterested in, a list consisting of the information of howoften an action was proceeded for a given version ofthis library.

[ ( Vers ionDowngraded, Vers ionUpgraded, V e r s i o n S t a y e d, VersionRemoved ) ]

The second approach, which we introduce in this paperas an extension to Mileva et al., concerns the proceededupgrade- and downgrades by a certain library (orrespectively its developers). For an arbitrary librarywe are interested in, we can conveniently summariseour findings into a quadruple containing the number oftimes certain actions were proceeded over the courseof all available versions of this library.

( DependencyDowngraded, DependencyUpgraded

, DependencyStayed, DependencyRemoved )

4.2. Reasoning about switching library ver-sions

Where the research of Mileva et al. stops after gath-ering the information and combining them to discoverusage trends in libraries and their versions, we are ofthe opinion that more relevant data can be extractedfrom this information if a little bit more of researchwas to be done. To be able to discover the specificreasons why software developers switch back to anolder version of the library or decide to abandon alibrary in its whole for another library, we will digdeeper into the commits when the change in libraryhappened. Information that we will try to obtain fromthese commits are the reasons behind the decision tochange a library (version).

The following part of this section will explain indetail how we used existing research for the purposeof categorising commits into reasons. Based on thecombination of these different categories, we willdetermine a specific reason behind the commit. Usingthese methods, we will obtain the data needed toanswer the second question.

4.2.1. Data Collection.

Collecting data.For the data we want to look at, we take the topdownloaded and highly used libraries available atHackage. In the end, libraries are just a projectas well and it complements the data used inour first research question. For every of thoselibraries, we then consider all the commits thatwere stored in their version control system. Ourdata set consists of all the commits of in total1250 Haskell libraries.

Determining interesting commits.After collecting all the commits in the previousstep, we go through all of them and filterthem based on whether they are interesting forour research question. The commits that areinteresting for us are the commits in which adependency was changed. Whether it was addinga library, removing a library or changing alibrary version. They way in which we determinewhether a commit has changed a dependency

is by looking through the files changed inthe version control system of the project andchecking if the dependency manager file isincluded in these. In Hackage projects, this is the.cabal file at the root of the project. If no changewas recorded in the .cabal file for a certaincommit, we discard the commit and move on. Intotal, at this stage we are left with 659 interestinglibraries and 37148 interesting commits.

Pre-processing commits messages.Before we continue with our analysis of themessages involved in the commits, we haveto pre-process the messages to obtain usefulinformation out of them. First, we remove thenon-characters using regular expressions. Then,we remove the stop words because they arefrequent appearing words that are not interestingfor us in any way. Lastly, we stem all theremaining words to be able to group themtogether. For example, ”fixed” and ”fix” shouldbe matched together. To obtain this, we have tostem all the remaining words. The word ”fixed”will then be reduced to its root ”fix”. These lasttwo steps are performed using NTLK5. All thistogether, is called normalisation.

Determining category of the commit.After determining which commits are interestingfor our research question, we classify them usinga bag of keywords [3], [4]. The bag of keywordsthat we used is extracted from research done byMauczka et al. In their research, they created analgorithm that trains and develops a weighteddictionary of keywords on itself for the purposeof classifying commits based on their commitmessages. The dictionary that they created usingtheir algorithm had a classification rate of 80.34%based on 8 open source projects, which all hadat least 30,000 commits [5]. In this step, we usethe final dictionary created by Mauzcka et al.’salgorithm to classify all the interesting commitsinto 3 categories: Corrective commits, Adaptivecommits and Perfective commits [5], [6].

• Corrective Commits. Commits that containchanges for the purpose of fixing errors, failuresand bugs in performance or implementation.• Adaptive Commits. Commits that containchanges for the purpose of adding or changingfunctionalities.

5. http://www.nltk.org/

Figure 1. Flowchart displaying the different steps taken in the approach for research question 2.

• Perfective Commits. Commits that containchanges for the purpose of increasingperformance, decreasing redundancy andinefficiency, increasing maintainability andchanges to layout or style. We consider this pastthe point where features are already implementedand running.

Classification in reasons.After determining whether the commit we arecurrently considering is corrective, adaptive orperfective, we look into the changes made inthe .cabal file. More specifically, we look intothe addition and deletion of lines that concernthe dependencies of the current project. We cando this because the .cabal file is responsible fordependency managing and every dependency isspecified in exactly one line. Based on whethera library was involved in an addition or deletionand the category of the commit in which thesechanges happened, we classify them into anotherset of different categories. These categories arewhat we think is most logically implied by thecombination of the factors we just mentioned.Here, we will elaborate more on our reasoningbehind the combinations and their implication toour specified categories. In Table 1 there will bea summary of all these combinations and theirderived categories.

Addition and Corrective. This combinationis probably the best useful feedback a librarydeveloper can receive. The addition of a libraryin a corrective commit first of all means that thelibrary fixes some failure or error in the project ofthe developer and thus is doing something good.Secondly, if this is combined with the deletion of

Change Category ReasonAddition Corrective Compatible with the projectAddition Adaptive Dependency needed for new patch or featureAddition Perfective Improvement of projectDeletion Corrective Removed for bugfixDeletion Adaptive Compatibility issuesDeletion Perfective Not relevant / Unused

Table 1. Reasons behind the change independency based on the type of source code

change and the commit category.

another library, it most likely also means that forthis particular developer and project the library isbetter compared to other similar libraries. In theend, the similarity in these reasons is the fact thelibrary added is compatible with the project. Thisis in two ways: either another library introducesa bug or error which this library fixes, whichmeans that this library is more suited for theproject, or the library fixes some issue in theproject, which means it is compatible with theproject. Compatible.

Addition and Adaptive. This combination isprobably the most straightforward combination,in our opinion. The addition of a library inan adaptive commit means that the library isrequired for correctly implementing a certainpatch or feature. Thus meaning that the libraryadded is beneficial for the project and aids in theimplementation of a feature in the project in asuitable way. Feature.

Addition and Perfective. For the combination ofa library being added in a perfective commit, thereare a wide range of scenarios imaginable. Either

a library was added to increase performanceor maintainability, decrease inefficiency orstylistically changes. These possible scenariosdiffer so much from each other that they arehard to group together. The only thing wecan guarantee, is that this combination is aimprovement of the project. Improvement.

Deletion and Corrective. When a library isdeleted in a commit responsible for fixing errors,faults and bugs (Corrective), it is very likelythat the the usage of the library introducedunforeseen and undesired consequences into theproject. Therefore, the library dependency has tobe dropped in order to remove or fix the bug(s).Bug.

Deletion and Adaptive. The deletion of a libraryin a commit that is responsible for adding orchanging functionalities (adaptive) normallyhas two possibilities. Either the library thatis removed from the project is not what thedeveloper wanted from the library, or it was notcompatible with the project, or the developerfound another library that is better suited for hisproject in functionalities and/or compatibility.All in all, the main similarity in all these reasonsis that the library and project are not compatiblewith each other, in ways of actual compatibilityand how suitable the library is for the project.Non-Compatible.

Deletion and Perfective. As we considerperfective commits to be past the points of actualimplementation, no major changes would bemade in perfective commits involving changes inlibrary dependencies. Only minor changes willbe made like cleaning up or beautify the sourcecode. In these cases, the deletion of a librarydependency will most likely be the removal ofdue to it not being used or wanted anymorebecause it was replaced by another. Replaced.

This classification will be done for every libraryand its version as specified in the .cabal file.After the whole process of data collection wewill obtain for every library with its version theamount of occurrences for each of the combi-nations specified above. The format of the dataobtained is as follow:

[ L i b r a r y ,#ADD�COR, #ADD�ADP, #ADD�PER ,

#DEL�COR, #DEL�ADP, #DEL�PER]

Parts of this data will be showed in Section 7 andwe will also try to derive trends based on this dataand also evaluate onto these derivations there.

5. Library Usage Trends

To find trends amongst library versions we com-pared the mined results of common libraries. One ofthe results can be seen in figure 2 which shows anormalised stacked bar chart. The chosen libraries werecommonly used libraries: dictionary, bytestring, base,lens, cabal, time and containers because most projectsrely on these libraries, making them interesting to lookat.

To find patterns we looked at the following:

• Trends of the dominating library version. A versionis considered to be dominating if is holds more than0.3 of the total shares.• Total duration that a library was used frequently. Aversion is considered to be in use if it has a value of 0.2or above. Everything below this threshold is not takeninto consideration since they will not have a statisticalmeaning on major trends.• Shape of the bars of a specific library version. So forexample, do when see values like 0.2, 0.3, 0.4, 0.3, 0.2it indicates that a version is slowly becoming popular.Another possibility is that we see values like 0.3, 0.3,0.3, 0.2 which could be an indication that a versionreached its highest popularity rapidly.

During the evaluation we will ignore small resultsbecause they are not of interest when finding majortrends. These usages are most likely from projectsthat cling to a specific version for which everythingworks and do not consider switching. We can seesimilar trends between different libraries which we willdiscuss next. The differences will be also be brieflydiscussed.

When looking at the similarities we first see thatwhen looking at dominating versions it can be ob-served that a version will quickly grow in use to bea dominating version once launched or be a versionthat is never used frequently. This can also be seen infigure 2 where four dominated versions are highlightedwith white in the centre. It is also noticeable that theusage trends grown almost immediately after the firstoccurrence of the version after which they gradually

Figure 2. Stacked bar chart of the contributions of the versions to the total usage of the Haskell library time.Bars that are white in the centre indicate some of the dominating versions which means that they contributeto more than 0.3 for some amount of time.

decrease in usage and make place for a next domi-nating version. Versions are taken in use quickly anddiscarded slowly but almost never discarded entirely.

When looking at the duration of used libraries weobserve that the usage of a version is decreasing whena new version is released that will grow into a domi-nating version. When this is not the case the changesin version usage are minimal. So the introduction ofa new version does only influence the other versionusages if it will be successful. It is noticeable thatthis is the only influence on major changes in usagesof different versions. The results show that developersare likely to follow the behaviour of other developerswhich was expected as Mileva et al. found similarresults for projects in Java.

There are few differences between the results. Thedifference that is most present in the results are theamount of versions that are being used at the sametime. For example, the library directory would mostof the times have 2 dominating versions, whereasbytestring has 3 or even 4 dominating versions simul-taneously. It is observed that libraries that have moreavailable versions have more simultaneous dominatingversions.

6. Switch-backs and Upgrades of LibraryVersions

This section will go in depth about the trends forlibrary upgrades and switch-backs. Resulting from ourapproaches introduced in Section 4.1.3, we presentswitch-back behaviour from two different point ofviews. First, from the perspective of a library executingswitch-backs on its dependencies. The second perspec-tive puts the library in the perspective of a dependencybeing switched-back (downgraded) by other libraries.

6.1. Insights from a library perspective

The data collected in regards of the number ofswitch-backs and upgrades proceeded by a library isrepresented by popular libraries like lens and cabal inthe following paragraphs.

We compared the results with the function

Rating = log(#upgrades+ 1

#switchbacks+ 1)

We add one in the fraction to prevent divisions byzero. Also, this results in a neutral line of Rating = 1where 1/10 should be as far from the neutral line as

Figure 3. Ratio between switch-backs and up-grades from a library where positive values in-dicate more upgrades and negative lower moreswitch-backs. lens on top and Cabal bottom

10/1. This is why the log is taken. The result is aline where negative values indicate more switch-backsthen upgrades and the reverse for positive values. Theresults of lens and Cabal can be seen in figure 3.

The results could be used to find behaviour inswitch-backs and upgrading. Firstly, a period wheremany downgraded occurred could give an indicationthat developers switched too early to newer versions.Secondly, if many stays are observed the version couldbe considered a sustainable.

The results show both similarities and dissimilar-ities. Firstly, we observe no similarities when peoplehave a tendency to switch back versions. We see thatswitch-backs mostly occur after a period of time ofmany upgrades. However, some switchbacks happenafter 1 year of the last upgrades and others after 1month so this behaviour shows no obvious patternwhen being compared.

Unfortunately, similarities are trivial. The amountof upgrades is always higher than the amount ofswitch-backs which should be the case. The otherobservation is that a switch-back will never occurbefore an upgrade which also is logical behaviour.

Concluding, the behaviour for switching back orupgrading the library version is strongly dependent onthe library. If a new version is released which causescompatibility issues it is more likely that more switch-backs will occur. Therefore, it is difficult finding apattern for upgrading and switching back versionswithout knowing the real reason behind it (e.g. thelibrary contained a bug) which is a semantic problem.This was also researched and the results can be foundin the following section.

6.2. Insights from a dependency perspective

The second perspective gives information abouthow often a library, being used as a dependency, wasswitched back or upgraded. The results clearly showthat one can read a trend of versions being switch-backed over time. As an example, Table 2 contains themost interesting versions of the base library. Interestingmeaning, that either switch-backs, upgrades or staysmakes more than 10% of their corresponding totalgiven all available versions. In total this means for theparticular case of base:

Total downgrades: 137.0Total upgrades: 162.0

Total stays: 2225.0Total removes: 20.0

One can easily extract that, version resolving underthe version definition (> 1&& < 1) are switched bymore than 10% of all the libraries using base as adependency, whereas for (== 4.) it is slightly morethan 5%. Interesting to see is that people are startingto switch to base version 5, indicating by the slightswitch-back rate of (>= 4&& < 4.8).

Switch-backs(%)

Upgrades(%)

Stays(%)

(’base’, ’ (==4.*)’) 5.56 0.00 14.11(’base’, ’ (>1 && <1)’) 10.49 0.00 0.09

(’base’, ’ (>=4 && <4.8)’) 0.62 10.22 2.61(’base’, ’ (>=4.3 && <5)’) 0.00 25.55 15.33

Table 2. Insight into the 10% most interestingversions of base library in regards of

switch-backs, upgrades or stays.

7. Reasons behind Library Changes

In this section, we study the reason behind thelibrary changes using the mined data as described in

Figure 4. The number of library dependenciesthat were categorised into ADD-COR. Indication ofCompatibility of dependency.

Section 4.2. We obtained 2220 unique library depen-dencies from the dependency files of the top down-loaded libraries of Hackage. Each of these dependen-cies were checked for the categories as explained in”Classification in reasons” of Section 4.2.1. From thisdata, we aim to obtain the trends and draw inferencesover the possible reasons for change in libraries.

For studying the trends in the library changes,the relative statistics of the categories were of morerelevance than their respective individual statistics.The statistics were divided into 4 bins of relativeoccurrence: category occurrences from 0 - 0.25, 0.25- 0.50 - 0.50 - 0.75 and 0.75 - 1.0. Figure 4 showsthat almost over 1421 libraries had a maximum of25% of ”Compatible” feature. This indicates that notmany libraries were changed due to compatibilityissues. Additionally, figure 5 shows that over 50%of the library dependencies were categorised as either”ADD-ADP” or ”DEL-ADP”. As described in Section4.2, this categorisation indicates that over 50% of thedependencies were changed(added or deleted) to eitherintroduce a new Feature or address the compatibility ofa Feature that might have been introduced in an earlierversion. Furthermore, figure 6 shows that only around500 dependencies were removed as they introduced”Bugs” or were indirectly associated with them. Thatnumber is less when compared to the total number ofdependencies that were changed.

If we refer to the figure 5, it is quite evident thatthe developers have mostly either added or deleteda dependency due to corrective or adaptive measureswhile perfective measures where of much less concern.

To further support our reasoning about librarychanges, we correlate the categorisation of the librarywith the stats from its switchbacks. We have selectedone of the most downloaded and used library depen-

Figure 5. Distribution of the libraries over theclassification categories.

Figure 6. The number of library dependenciesthat were categorised into DEL-COR. Indication ofintroduction of Bug by the library.

dency from the Hackage, namely, lens package. We ob-served that lens had the most number of commits(515commits) that modified it’s dependency file. Figure7 gives some interesting yet consistent trends. Lenshas been upgraded 30% of the time to address orintroduce a Feature. It also indicates that the libraryhas been upgraded over 60% of the time to maintainstability of the package. This trend can be validatedwith respect to the switchbacks and upgrades of itsversion as described in Section 7 and figure 3.

In conclusion, the trend that we observed fromour mined data was that majority of the librarieswere upgraded to introduces new features and addressthe compatibility of other newly added dependencies.Most of the popular libraries showed equal numberof addition and deletion of their library versions andsimultaneously being categorised into corrective andadaptive metrics, thus indicating that these librariesare quite stable and are upgraded to avoid bugs orincompatibility issues creeping due to introductionof newer libraries. Interestingly, the libraries that we

Figure 7. Distribution of lens library in the sixcategories.

studied were not much affected by perfective measureslike errors in documentation, refactoring or increasingefficiency and maintenance. This might be an indica-tion that the developers in the Haskell community havealready ensured good level of stability and efficiency.However, it could also mean that not much importanceis given to these kind of measures as compared to othermeasures like preventing bugs and adding features. Webelieve that by mining and analysing more commitmessages in future, we could possibly state betterinferences about the ”perfective” measures.

8. Threats to Validity

We discuss some limitations that must be consid-ered when interpreting the outcomes of the research.The following points are threats to validity:

Results might now hold for projects using differentprogramming languagesThe decision to compare the results of Milevaet al. with Haskell was because Haskell is afunctional programming language in contrastto Java. Mileva et al. have claimed that ”thelibraries used in a project depend on the scopeof the project and not on its managementtools”. We make the same claim and append itthat by comparing it with a different type ofprogramming language we have a more scatteredsample set making the results less biased andthus more reliable.

Sample set may have biased the outcomesBy taking the top downloaded Haskell projectswe took a sample set that is large enough tomake conclusions about and simultaneously

provide a sample set which is relevant becausethey are up-to-date and commonly used. Lesspopular projects do not contribute to the results.However, this filters out projects that are notrelevant to the research, such as small personalprojects. We believe that the less popular relevantprojects are represented in the large sample set.

Version definition resolver might be too naiveAs described in 4.1.3, the approach used toresolve the absolute version given a definitionof a version is naive in the way that onlythe definition itself is considered. However, amore appropriate approach might be to actuallyreconstruct the resolving process as was in thepast by considering the publication date of therelease of the library that uses the dependencybeing our suspect. Then combine those twoapproaches in order to retrieve most accurateresults.

Extend classification library changeFor research question 2, we combined theaddition or deletion of a library in the dependencymanager file with the category of the commitbased on the commit message. This resultedin six new categories that we used to identifydifferent reasons for certain changes in librarydependencies. However, in these six categorieswe only looked into the simple cases of either anaddition or either a deletion. More informationcould be extracted based on the addition ordeletion of another library in the same commit.In our analysis of the category combining anaddition with a corrective commit, we alreadymentioned such a case. If a certain library X wasadded to the dependencies in a corrective commitwhereas another library Y was deleted in thesame commit, we have more information and wecan make more specific conclusions. Instead oflibrary X being suitable and compatible for theproject, we can also derive that X is most likelymore suitable and compatible to the project thanlibrary Y. This could provide better feedback forlibrary developers to receive feedback on whattheir users want and what might be better inother competitors’ libraries. Instead of six newcategories, the classification could be extendedto twelve cases and most likely provide morein-depth reasons.

Time of usageAnother factor that was not taken into consid-

eration in the analysis of research question 2,which could be interesting, is the time periodover which libraries are used. Whereas the timethat a library is kept into a project might not bethat interesting, the time between adding a libraryand then removing it might be. This time-spancould provide more information about the reasonbehind the deletion of the library. If the librarywas removed shortly after it was added, it wasmost likely due to not containing the features thatthe developer desired or was not compatible withthe project. Whereas if the library was used fora longer period of time before being removed,it could tell something about the compatibilityissues with other libraries, maintainability or scal-ability. The influence of time can be sizable, buthas to me researched before any statement can bemade concerning it.

9. Related Work

There has been quite some research in relation toAPI usage trends. Steven et. al have performed similarstudies previously. Their study primarily focuses ondetermining the stability of an API and eventually,helping the developer in deciding whether to switchaltogether to another similar library or not. Accordingto their studies, they based their results by computingfour metrics: weighted number of removed methods,amount of change in existing methods, the ratio ofchange in new to old methods and the percentage ofmethods. Using these metrics they determine whethera change in method has caused a certain instability inthe library. This study could help us in our analysis ofswitchbacks of library versions by the developers [7].

Cedric et. al have studied about the various patternsof the library migration. They studied the dependencyof one library on another and used the library usagesas the weights for their metrics. Their result is quitepromising as their study helps the developer over thedecision of migration by showing them the graphsof migrating transition of the library. Although, thisresearch was based on individual java based librarybelonging to limited categories, we aim to performsimilar analysis on other languages as the methodologyinvolves mining of the dependency files and importstatements. Their study could also help us in improvingour analysis over version switchbacks as it wouldrequire mining of individual library versions ratherthan the individual libraries themselves. Regardingthe categorisation of software development based on

the commit messages and the source code, Mockusand Votta [4] have performed similar analysis. Theircategorisation methodology was based on keyword-detection. They categorised the commit messages theninto 3 categories. Our method for determining reasonsbehind switching of libraries is also based and inspiredby their methodology. To our best knowledge, there arequite less researches being performed on programminglanguages other than Java (Maven-based projects).Most of these studies show the developers to migrateto previous versions or other libraries but do not givethe reason behind the switchback. We believe that ourstudy could help in these aspects [8] .

Zhong et al. have built a tool which can recommendthe use of an API based on the usages of other project.This indicates if the programmer is using the rightsequence of API calls to prevent bugs [2] or give anindication to the programmer how to use the API toavoid searching how to use it properly.

10. Conclusion

This paper tried to find patterns in usage trendsfor library usage by looking at a various amount ofprojects written in the programming language Haskell.

This paper presented an approach on how to findpatterns in library usage behaviour. Techniques weredeveloped to find the general trends in the usage and tofind patterns in switch-backs and upgrades of a libraryversion. Another technique was developed to gain anunderstanding in the reasons behind the trends. Basedon existing research and information provided by theversion control system, we provided a technique tocategorise commits into six different reasons for thechange in library dependency.

The results showed that developers are likely tobe attracted to similar library versions and that a newversion is either successful or almost never used. Theoverall trend in the usage of such successful versions isa period where the usage rapidly increases after whichthe usage slowly declines. It was also noticed thesesuccessful versions are almost never discarded entirely.This proves that the results of Mileva et al. also holdfor Haskell since developers are likely to follow othersbehaviour.

When looking at the qualitative results of switch-backs and upgrades we found that it is difficult tomake statements about them since they are different forevery library. No trends can be found when looking at

numbers only. There must be looked at the underlyingreason behind the switch-back or upgrade to makevalid statements.

From the results for the second research question,we observed that that majority of the libraries wereupgraded to introduces new features and address thecompatibility of other newly added dependencies. Mostof the popular libraries showed equal numbers ofcorrective and adaptive changes, which is a positiveindication for the stability and usage of the libraries.Not a lot of libraries were affected by perfectivemeasures. This could be due to factors like stabilityand efficiency of the libraries, but based on the data wehave at hand this can not be concluded with certainty.

Acknowledgment

We would like to thank the Delft University ofTechnology as well as the Hackage Community forproviding necessary resources. We also would like toespecially thank Alberto Bacchelli and Anand Sawantfor guiding us in the field of Mining Software Repos-itories and providing counsel and feedback.

References

[1] Y. Mileva, V. Dallmeier, M. Burger, and A. Zeller,“Mining trends of library usage,” in Proceedings of thejoint international and annual ERCIM workshops onPrinciples of software evolution (IWPSE) and softwareevolution (Evol) workshops. ACM, 2009, pp. 57–62.

[2] H. Zhong, T. Xie, L. Zhang, J. Pei, and H. Mei,“Mapo: Mining and recommending api usage patterns,”ECOOP 2009–Object-Oriented Programming, pp. 318–343, 2009.

[3] B. Ray, V. Hellendoorn, Z. Tu, C. Nguyen, S. Godhane,A. Bacchelli, and P. Devanbu, “On the naturalness ofbuggy code,” in Proceedings of the 38th InternationalConference on Software Engineering. ACM, 2016, pp.428–439.

[4] A. Mockus and L. Votta, “Identifying reasons forsoftware changes using historic databases,” in SoftwareMaintenance, 2000. Proceedings. International Confer-ence on. IEEE, 2000, pp. 120–130.

[5] A. Mauczka, M. Huber, C. Schanes, W. Schramm,M. Bernhart, and T. Grechenig, “Tracing your mainte-nance work–a cross-project validation of an automatedclassification dictionary for commit messages,” in In-ternational Conference on Fundamental Approaches toSoftware Engineering. Springer, 2012, pp. 301–315.

[6] A. E. Hassan, “Automated classification of change mes-sages in open source projects,” in Proceedings of the2008 ACM symposium on Applied computing. ACM,2008, pp. 837–841.

[7] S. Raemaekers, A. van Deursen, and J. Visser, “Measur-ing software library stability through historical versionanalysis,” in Software Maintenance (ICSM), 2012 28thIEEE International Conference on. IEEE, 2012, pp.378–387.

[8] C. Teyton, J. Falleri, and X. Blanc, “Mining librarymigration graphs,” in 2012 19th Working Conferenceon Reverse Engineering. IEEE, 2012, pp. 289–298.