Fixed typography and fixed missed comma in Russian version

In Russian text «double angle quotation marks» should be used.

And there’s missed comma at one place.

lang/ru/index.md

@@ -22,7 +22,7 @@ title: Семантическое Версионирование 2.0.0
 Вступление
 ----------
 
-В мире управления процессом разработки есть понятие "ад зависимостей"
+В мире управления процессом разработки есть понятие «ад зависимостей»
 (dependency hell). Чем больше растёт ваша система и чем больше библиотек вы
 интегрируете в ваш проект, тем больше вероятность оказаться в этой ситуации.
 
@@ -35,7 +35,7 @@ title: Семантическое Версионирование 2.0.0
 с будущими версиями).
 
 В качестве решения данной проблемы я предлагаю простой набор правил и
-требований, которые определяют как назначаются и увеличиваются номера версий.
+требований, которые определяют, как назначаются и увеличиваются номера версий.
 Для того чтобы эта система работала, вам необходимо определить публичный API.
 Он может быть описан в документации или определяться самим кодом. Главное,
 чтобы этот API был ясным и точным. Однажды определив публичный API, вы
@@ -45,27 +45,27 @@ API, увеличивают патч-версию, обратно совмест
 увеличивают минорную версию и обратно несовместимые изменения API увеличивают
 мажорную версию.
 
-Я называю эту систему "Семантическое Версионирование" (Semantic Versioning). По
+Я называю эту систему «Семантическое Версионирование» (Semantic Versioning). По
 этой схеме номера версий и то, как они изменяются, передают смысл содержания
 исходного кода и что было модифицировано от одной версии к другой.
 
 
 Спецификация Семантического Версионирования (SemVer)
 ------------------------------------------
 
-Слова "ДОЛЖЕН" (MUST), "НЕ ДОЛЖЕН" (MUST NOT), "ОБЯЗАТЕЛЬНО" (REQUIRED),
-"СЛЕДУЕТ" (SHOULD), "НЕ СЛЕДУЕТ" (SHOULD NOT), "РЕКОМЕНДОВАННЫЙ" (RECOMMENDED),
-"МОЖЕТ" (MAY) и "НЕОБЯЗАТЕЛЬНЫЙ" (OPTIONAL) в этом документе должны быть
+Слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ОБЯЗАТЕЛЬНО» (REQUIRED),
+«СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДОВАННЫЙ» (RECOMMENDED),
+«МОЖЕТ» (MAY) и «НЕОБЯЗАТЕЛЬНЫЙ» (OPTIONAL) в этом документе должны быть
 интерпретированы в соответствии с [RFC 2119](http://tools.ietf.org/html/rfc2119).
 
 1. ПО, использующее Семантическое Версионирование, должно объявить публичный
 API. Этот API может быть объявлен самим кодом или существовать строго в
 документации.  Как бы ни было это сделано, он должен быть точным и
 исчерпывающим.
 
-1. Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z - неотрицательные
-целые числа и НЕ ДОЛЖНЫ начинаться с нуля. X - мажорная версия, Y - минорная
-версия и Z - патч-версия. Каждый элемент ДОЛЖЕН увеличиваться численно.
+1. Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z — неотрицательные
+целые числа и НЕ ДОЛЖНЫ начинаться с нуля. X — мажорная версия, Y — минорная
+версия и Z — патч-версия. Каждый элемент ДОЛЖЕН увеличиваться численно.
 Например: 1.9.0 ->1.10.0 -> 1.11.0.
 
 1. После релиза новой версии пакета содержание этой версии НЕ ДОЛЖНО быть
@@ -137,29 +137,29 @@ API. Этот API может быть объявлен самим кодом и
 -------------------------------------------------
 
 Это не новая или революционная идея. Вероятно, вы уже используете что-то
-подобное. Проблема в том, что "подобное" - не достаточно хорошо. Без
+подобное. Проблема в том, что «подобное» — не достаточно хорошо. Без
 соответствия формальной спецификации, номера версий практически бесполезны для
 управления зависимостями. Ясно определив и сформулировав идею версионирования,
 становится легче сообщать о намерениях пользователям вашего ПО. Когда эти
 намерения ясны, гибки (но не слишком), спецификации зависимостей наконец могут
 быть созданы.
 
 Простой пример демонстрирует, как Семантическое Версионирование может сделать
-"ад зависимостей" вещью из прошлого. Представим библиотеку, названную
-"Firetruck". Она требует Семантически Версионированный пакет под названием
-"Ladder". Когда Firetruck был создан, Ladder был 3.1.0 версии. Так как Firetruck
+«ад зависимостей» вещью из прошлого. Представим библиотеку, названную
+«Firetruck». Она требует Семантически Версионированный пакет под названием
+«Ladder». Когда Firetruck был создан, Ladder был 3.1.0 версии. Так как Firetruck
 использует функционал версии 3.1.0,  вы спокойно можете объявить зависимость от
 Ladder версии 3.1.0, но менее чем 4.0.0. Теперь, когда доступен Ladder 3.1.1 и
 3.2.0 версии, вы можете интегрировать его в вашу систему и знать, что он будет
 совместим с текущим функционалом.
 
 Как ответственный разработчик, вы, конечно, хотите быть уверены, что все
 обновления функционируют как заявлено. В реальном мире полный бардак и ничего
-нельзя с этим поделать. Что вы можете сделать - это дать Семантическому
+нельзя с этим поделать. Что вы можете сделать — это дать Семантическому
 Версионированию предоставить способ выпуска релизов без выпуска новых версий
 зависимых пакетов и сохранить вам время и нервы.
 
-Если это звучит соблазнительно, всё что вам нужно - это начать использовать
+Если это звучит соблазнительно, всё что вам нужно — это начать использовать
 Семантическое Версионирование, объявить, что вы его используете, и следовать
 правилам. Добавьте ссылку на этот сайт в вашем README, тогда пользователи будут
 знать правила и извлекать из этого пользу.
@@ -170,7 +170,7 @@ FAQ
 
 ### Что я должен делать с ревизиями в 0.y.z на начальной стадии разработки?
 
-Самое простое - начать разработку с 0.1.0 и затем увеличивать минорную версию
+Самое простое — начать разработку с 0.1.0 и затем увеличивать минорную версию
 для каждого последующего релиза.
 
 ### Как я узнаю, когда пора делать релиз 1.0.0?
@@ -194,7 +194,7 @@ FAQ
 релизов с обратно несовместимыми изменениями означает, что вам придётся думать о
 последствиях ваших изменений и учитывать соотношение цена/качество.
 
-### Документирование всего API - слишком много работы!
+### Документирование всего API — слишком много работы!
 
 Это ваша ответственность, как профессионального разработчика, правильно
 документировать ПО, предназначенное для широкого использования. Управление
@@ -235,7 +235,7 @@ FAQ
 
 ### Что делать с устаревшим функционалом?
 
-Объявление функционала устаревшим - это обычное дело в ходе разработки и часто
+Объявление функционала устаревшим — это обычное дело в ходе разработки и часто
 необходимо для продвижения вперёд. Когда вы объявляете устаревшим часть
 публичного API, вы должны сделать две вещи: (1) обновить вашу документацию,
 чтобы дать пользователям узнать об этом изменении; (2) выпустить новый релиз с
@@ -264,4 +264,4 @@ GitHub](https://github.com/mojombo/semver/issues).
 Лицензия
 --------
 
-[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
+[Creative Commons — CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)