+++ /dev/null
-## Why do we need a versioning policy?
-
-Why? Because it's firmware and it's not tightly coupled to the driver.
-
-The firmware will be used by various projects for NIC support. It's not just for ath9k_htc - hopefully OpenBSD will adopt it soon; FreeBSD/NetBSD will adopt it as soon as there's a driver available.
-
-Since some downstream projects may wish to fork the github repository and do some of their own local development, each major and minor release will be a branch.
-
-## Ok, what's the policy?
-
-The policy is thus:
-
-1. No non-backwards compatible changes will occur on a major branch;
-2. Minor version numbers may introduce new features but they must be optional and default to the previous firmware behaviour;
-3. Major branch numbers may introduce non-backwards-compatible features.
-
-So:
-
-* Everything along the 1.x branch will be backwards compatible.
-* There'll be a branch laid down for each minor revision released (eg 1.3, 1.4, 1.5).
-* There'll be a tag laid down for each release along the minor revision (eg 1.3.1, 1.3.2, 1.3.3, etc.) which will match up with the binary firmware image that is released for public consumption.
-* 1.3, 1.4, 1.5, etc can introduce new features, but they must be optional and default to the previous behaviour.
-
-Hopefully what will be pushed into linux-firmware.git will be the latest of each major release version. Ie, there will only be one "current" firmware release in linux-firmware.git for 1.x, 2.x, 3.x, etc.
\ No newline at end of file
--- /dev/null
+## Why do we need a versioning policy?
+
+Why? Because it's firmware and it's not tightly coupled to the driver.
+
+The firmware will be used by various projects for NIC support. It's not just for ath9k_htc - hopefully OpenBSD will adopt it soon; FreeBSD/NetBSD will adopt it as soon as there's a driver available.
+
+Since some downstream projects may wish to fork the github repository and do some of their own local development, each major and minor release will be a branch.
+
+## Ok, what's the policy?
+
+The policy is thus:
+
+1. No non-backwards compatible changes will occur on a major branch;
+2. Minor version numbers may introduce new features but they must be optional and default to the previous firmware behaviour;
+3. Major branch numbers may introduce non-backwards-compatible features.
+
+So:
+
+* Everything along the 1.x branch will be backwards compatible.
+* There'll be a branch laid down for each minor revision released (eg 1.3, 1.4, 1.5).
+* There'll be a tag laid down for each release along the minor revision (eg 1.3.1, 1.3.2, 1.3.3, etc.) which will match up with the binary firmware image that is released for public consumption.
+* 1.3, 1.4, 1.5, etc can introduce new features, but they must be optional and default to the previous behaviour.
+
+Hopefully what will be pushed into linux-firmware.git will be the latest of each major release version. Ie, there will only be one "current" firmware release in linux-firmware.git for 1.x, 2.x, 3.x, etc.
\ No newline at end of file