<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Decisions on Selenium</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/tags/decisions/</link><description>Recent content in Decisions on Selenium</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 05 Apr 2024 05:24:49 -0500</lastBuildDate><atom:link href="https://deploy-preview-2575--selenium-dev.netlify.app/tags/decisions/index.xml" rel="self" type="application/rss+xml"/><item><title>Moving to Trunk</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2020/moving-to-trunk-development/</link><pubDate>Wed, 01 Jul 2020 00:00:00 +0000</pubDate><guid>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2020/moving-to-trunk-development/</guid><description>&lt;p>Since the project started we have been following &lt;a href="https://trunkbaseddevelopment.com/">trunk based development&lt;/a>. This was a very natural fit when we were using SVN over a decade ago on Google Code.&lt;/p>
&lt;p>As Google Code shut down we moved to GitHub and the git model of doing things. We moved there mostly due to the gravity that GitHub had created in Open Source projects.&lt;/p>
&lt;p>This meant that we followed the standard use of &lt;code>master&lt;/code> as our trunk to work off. Now that GitHub, and services that use GitHub, have improved support for non-master branches as default we are moving our default branch to &lt;code>trunk&lt;/code>. It describes how we, as a project, work and is a more inclusive term.&lt;/p></description></item><item><title>Source Control</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2013/source-control/</link><pubDate>Mon, 14 Jan 2013 00:00:00 +0000</pubDate><guid>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2013/source-control/</guid><description>&lt;p>This short technical note is to announce that the Selenium project is now using &lt;a href="https://code.google.com/p/selenium/source/checkout">git on Google Code&lt;/a> in place of subversion.&lt;/p>
&lt;p>The move has been a long time in the making, and it’s largely thanks to the efforts of &lt;a href="https://twitter.com/krosenvold">Kristian Rosenvold&lt;/a> that we’ve been able to do the migration and retain the project history. The project owes him a huge thank you! We’re in the process of migrating the last bits and pieces (none of which are user facing), so there may be some last minute turbulence as we settle everything down.&lt;/p></description></item><item><title>Going Atomic: How</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2010/going-atomic-how/</link><pubDate>Sun, 05 Sep 2010 00:00:00 +0000</pubDate><guid>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2010/going-atomic-how/</guid><description>&lt;p>This is the second of my technical posts. Again, if you’re interested in the internal workings of Selenium 2, then please skip straight to something else. If you’re interested in how and why we made some of the technical decisions on the project, keep reading….&lt;/p>
&lt;p>We left our intrepid heroes in a tight spot: they’d decided to write a shared library of code, to be used by the various webdriver implementations and selenium core, but the requirements for doing this seemed to be at odds with it actually happening.&lt;/p></description></item><item><title>Going Atomic: Why?</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2010/going-atomic-why/</link><pubDate>Mon, 16 Aug 2010 00:00:00 +0000</pubDate><guid>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2010/going-atomic-why/</guid><description>&lt;p>This is the first in a series of technical posts by me about the internals of Selenium WebDriver. If you’re not interested in technical nitty-gritty, then feel free to step away now.&lt;/p>
&lt;p>Still here? Excellent.&lt;/p>
&lt;p>Let’s take a step back to just before the Selenium and WebDriver projects merged. There were, very obviously, two separate codebases. Looking closer and with a slightly different perspective, there were more than this. We used the test suites for webdriver to define the behaviour for multiple, largely independent, driver codebases. The &lt;a href="http://code.google.com/p/selenium/source/browse/#svn/trunk/jobbie">IE driver&lt;/a> was written in C, the HtmlUnit driver in Java and the &lt;a href="http://code.google.com/p/selenium/source/browse/#svn/trunk/firefox">Firefox driver&lt;/a> is largely Javascript, and so on.&lt;/p></description></item></channel></rss>