Ruslan Brest, rb.labtodo.com
Backend web-developer: CodeIgniter, PHP, MySQL, OpenCart, PrestaShop, MaxSite CMS

Opencart CE (Community Edition)

Давно я ожидал появления альтернативной версии репозитория Опенкарт с более адекватным ведением дел. Вообще-то думал, что он чуть раньше появится. Но чтобы его объявили прям в "новостях и анонсах" на форуме -- не ожидал. Смело :) Я думал, будет как-то менее заметно и в одном из репо десятка-другого активных разработчиков и комиттеров, разочаровавшихся в политике DK. Респект rph :)

Вообще-то в какой-то момент, когда Qphoria начал бранчи в гитхабе изучать, я поверил, что не всё потеряно. Но потом опять началось, ДК ничуть не изменился. Workflow в гитхабе также остался прежним.

В общем, на днях (21 июня) пара квалифицированных разработчиков (rph /opencarthelp/ и AddCreative как минимум) объявили о рождении "community edition" форка (ответвления от основного репозитория Opencart). Судя по списку планируемых вопросов -- с этими людьми "кашу сварить" можно. И скорее даже нужно. Очень надеюсь, что там дело пойдёт намного лучше по части совместной разработки.

Основной упор Opencart CE собирается делать на немного измененном цикле жизни версий Опенкарт: поддержке отдельных веток для устаревающих версий и внесению исправлений обнаруженных ошибок не только в главную текущую ветку разработки, но и в ветки более старых версий.

Чтобы было чуть более понятно, надо пояснить, как сейчас ведутся дела.

Дальше я буду оперировать понятиями, привычными для Git.

  • По-хорошему, обычно принято, чтобы в главной ветке (`master` или `trunk`) находилась стабильная версия проекта. Которую любой разработчик или пользователь может взять и смело выгрузить на production server и быть уверенным, что работает со стабильной и проверенной версией продукта.
  • В девелоперской ветке ведётся основная работа: там расположена текущая, самая свежая, но необязательно стабильная, версия. Там могут быть ошибки и вообще содом и гоморра. Это не для конечных пользователей. Когда там всё устаканивается и протестировано, изменения из `dev` ветки вливаются в `master` и выпускается новый релиз.
  • Если версии рассматриваются просто как вехи в истории, которые в будущем не исправляются, а предполагается работа с последней, наиболее свежей версией -- достаточно просто помечать их тегами. Тег в гите - это просто закладка с именем.
  • Если надо версии сопровождать какое-то время -- они должны выделяться в отдельные ветки. Тогда при обнаружении и исправлении каких-то ошибок надо внести исправления во все поддерживаемые ветки (версии), где эта ошибка присутствует.

Вот вкратце и всё. Можно ещё упомянуть, что гораздо разумнее работу в `dev`-ветке также вести в отдельных ветках (небольших, временных, с префиксами `feat-` и `fix-`). Во-первых, это способно избавить ветку от мусора и мешанины при активной работе (особенно командной, но и при работе в одиночку это справедливо) и сделать историю гораздо более понятной. Во-вторых, фикс, находящийся в отдельной ветке, можно легко и просто применить к множеству ветвей с версиями. Без выколупывания diff-ов, patch-ей и ручной работы.

В Опенкарт (главном репозитории):

  • вся разработка ведётся в единственной ветке. То есть по факту это девелоперская, "грязная" ветка;
  • релизы никак не помечаются тегами, что очень сильно затрудняет обнаружение конкретной версии в истории. По сути, обнаружить место релиза нереально, если только не успел сам отметить в своем репозитории момент выпуска новой версии. Или по каким-то косвенным признакам и комментариям, может по дате;
  • не устанавливаются никакие связи с багтрекером (вернее, issue tracker-ом), про "smart commit messages" DK тоже не в курсе и продолжает постить в историю сплошной поток изменений. Понять, где именно был пофиксен какой-то баг?... А вот фигвам. Поди найди через полгода или даже через неделю, что было сделано для исправления ошибки, отчет о которой читаешь.

В новом репо (Opencart CE) версии будут выделяться в самостоятельные ветки и сопровождаться в будущем силами сообщества. То есть теперь гораздо больше шансов, что версия 1531 (например) получит все возможные исправления и не надо будет обновляться до 1551 (которая со своими новыми фичами никак вас не волнует, поскольку ничего нужного вам там не появилось).

То есть можно будет заходить в ветку своей версии, скачивать там последний доступный архив и обновлять свою версию более безболезненным способом.

Будем следить за развитием событий!

Links

twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru digg.com friendfeed.com liveinternet.ru livejournal.ru yandex.ru del.icio.us
Комментариев: 2
  1. Как мне кажется, удобство с ветками будет не таким важным плюсом (а для конечного пользователя это вообще что-то малопонятное), как более быстрое развитие всего ОС - без монополии в лице ДК

  2. 2013-07-01 в 09:21:09 | Ruslan Brest

    Да конечный пользователь вообще не при чём. О нём вообще речь не идёт. Главная проблема в полной оторванности репозиториев и исключительно ручной синхронизации. То есть обмен решениями и обновлениями затруднён в обе стороны. А чем это заканчивается - мы уже видели и знаем. В общем, там народ упорно идёт по натоптанным граблям.

    А приведёт это к постепенно возникающей разнице между проектами. Которую они будут пытаться синхронизировать только первое время. Потом надоест. И разойдутся проекты полностью.

Оставьте комментарий!

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Имя и сайт используются только при регистрации

Если вы уже зарегистрированы как комментатор или хотите зарегистрироваться, укажите пароль и свой действующий email. При регистрации на указанный адрес придет письмо с кодом активации и ссылкой на ваш персональный аккаунт, где вы сможете изменить свои данные, включая адрес сайта, ник, описание, контакты и т.д., а также подписку на новые комментарии.

Авторизация  Facebook. MaxSiteAuth. Loginza

(обязательно)