Survey results: How software ecosystems deal with breaking changes

xuanbao · · 477 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>Last fall we ran <a href="https://www.reddit.com/r/golang/comments/4x2wje/looking_for_info_on_how_go_package_developers/">a survey about how and why breaking changes are handled differently in 18 different software ecosystems, including Go</a>. We&#39;ve just submitted a paper to a conference about the results, and we&#39;ve also set up a site where you can <a href="http://breakingapis.org/survey">compare how different ecosystems perceived</a> their values, practices of upstream and downstream developers, and the health of their ecosystem.</p> <p>Results showed some stark differences between software communities, for example: <a href="http://breakingapis.org/survey/values.html#rapid?ecos=Haskell_Stack_Stackage_,Node_js_NPM,Ruby_Rubygems">Making updates available to end users quickly</a> was highly valued by Node and Ruby communities, but was considered less important to Eclipse. The Perl and Eclipse communities value <a href="http://breakingapis.org/survey/values.html#stability?ecos=Eclipse_plugins_,Haskell_Cabal_Hackage_,Perl_CPAN">stability</a> most, while Hackage/Cabal valued it least.</p> <p>Ecosystems have very different ways of dealing with versioning; for example in Go it&#39;s common for people to sometimes <a href="http://breakingapis.org/survey/upstream.html#mon_versionless_updates_eco?ecos=Go,Maven,Node_js_NPM">make small updates without increasing the version number</a>. In Rust, developers more frequently chip in and <a href="http://breakingapis.org/survey/downstream.html#sync_liaison_code?ecos=NuGet,Rust_Cargo">help with maintenance of upstream packages</a> than in NuGet. </p> <p>There are a lot of other results on the linked site, and we’re interested in your impressions of the results. Do the results make sense to you? What answers would you have expected? Do you think the differences are intentional? If you have any thoughts about it I’ll try to keep up with comments here, or you can also send us comments through the website. The <a href="https://figshare.com/articles/Culture_and_Breaking_Change_A_Survey_of_Values_and_Practices_in_18_Open_Source_Software_Ecosystems/5108716">anonymized raw data</a> is also available.</p> <p>We want to sincerely thank the large number of people in the Go community who responded, and we’re eager to hear what you think!</p> <p>Chris, Anna, Jim, and Christian</p> <hr/>**评论:**<br/><br/>Kraigius: <pre><p>Color me confused but isn&#39;t Eclipse an IDE, why is it compared to programming languages?</p></pre>cbogart: <pre><p>We surveyed people who develop plugins for Eclipse, rather than people who use Eclipse as an IDE.</p></pre>daenney: <pre><p>Bit of feedback wrt data presentation, having the text on the X axis rotated at 90 degrees makes my neck hurt because I need to bend it 45 degrees to be able to read it. Instead, consider putting the legend at about a 30-45 degree angle instead. If you want to keep it as it is then the text on the X axis should flow away from the axis instead of towards (the start of the word should be at the X axis, so mirror it over both the X and Y axis) as that helps with reading too.</p> <blockquote> <p>they encourage people to update their packages freely without regard to version numbers</p> </blockquote> <p>Considering the amount of work currently going on to provide a proper package manager, semver version ranges etc this might not hold true anymore. There&#39;s been quite some activism lately on ensuring people tag releases and version things in anticipation of <code>dep</code> getting more and more usage.</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

477 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传