Выпуск отдельных патч-обновлений


#1

Вновь подкралось ко мне желание обновиться… Ну вот иногда настигает оно меня. И будто за руку кто держит. Хотя я знаю, что на самом деле надо делать: надо просто какое-то (не)продолжительное время не заходить на этот форум. Тогда чувства притупятся и я смогу наконец-то нажать на эту заветную кнопку и на рабочем сайте. А пока…
Вот вроде и обновления регулярные, и ошибки исправляются… Одни исправляются - другие появляются, и так в каждом обновлении. В каждом! И ведь ладно, если что-то ненужное сломалось, так ломается всегда обязательно что-то нужное. Хотя, мы об этом и узнаем, скорее всего, потому что оно нужное. А о сломанном ненужном мы и не узнаем скорее всего, пока кто-то особо дотошный не доковыряется до всеми забытого уголка платформы или модуля.

Я все это к чему… Господа разработчики… Вы между обновлениями, могли бы запросто выпускать патч-версии обновлений. Или проще говоря: обновления - это там где что-то новое (только), а между ними - несколько или хотя бы один SP, маленький или большой, но со всеми исправлениями (только!), которые вы готовы к данному моменту предоставить.
Я понимаю, что с такими нововведениями вы разом потеряете большое количество бесплатных тестеров, но дадите своим пользователям дополнительную уверенность в том, что они не зря вас выбрали.


#2

Полностью поддерживаю! прям мысли из головы написали :slight_smile:


#3

Очень откликается, @imac не могли бы вы взять на вооружение. Нужна stable версия. Очень больно


#4

Было бы здорово, если бы обновление показывало, какие модули и в каком месте могут работать некорректно, так как они используют хуки или другие данные, которые изменились.


#5

Я вот недавно сказал уже, что политика эта странная, считать что пользователи платформы должны быть или программистами/unix-администраторами, либо им по барабану и они готовы у моря погоды ждать, за что меня слава богу не забанили на этот раз, но комментарий резко почистили.
Почему это должно выглядеть вот так?

Есть у вас эти diff файлы, лежат они у вас на сервере, есть у вас табличка в базе, где каждому diff прописано к каким версиям ядра и модулей он доступен.
Клиент при заходе в Центр обновления запрашивает информацию и при наличии у него высвечивается наличие патча под его версию. Нажимает кнопку и патч скачивается и устанавливается. Вааще без проблем же. Мало того - если чуток постараться - у вас же версификация нормально построена? делеаете вы патч под текущую версию - 4.13 например, но видите, что этот код не менялся по всей четвертой ветке - и ставите ему что он доступен для 4…0 + - и даже тот кто с 4.2 не обновлялся - сможет это сделать (не будем пока обращать внимание на то, что тогда, как и сейчас, такого механизма нет).
Что еще даст подобный инструмент?
Опять же то, о чем я вам лет пять твержу: поддержака работы с внешними сервисами. Яндекс, гугл, или кто еще помял что-то в своих настройках, изменил url запроса - и всё, сервис не работает. Хорошо, для тех кто купил платформу, платит за обновления и главное обновляется - вы выпускаете ОБНОВЛЕНИЕ. А для тех, кто за всё платит, но по какой-то причине не обновляется, через какое-то время часть платформы перестает работать, та часть, которая работает с внешними сервисами. А здесь ведь не зависит ничего от версии ядра, чаще всего - надо лишь изменить работу с внешним сервисом. И? Выпускаете патч, кому он доступен - применяет его и всё работает, все, абсолютно все довольны.
И это нормально. Это человеческое и правильное отношение к своим клиентам. Если они заплатили за ваш продукт, платя за обновления, они оплачивают ваш труд. Но если вы включаете в код работу с внешним сервисом - как мне кажется, вы просто обязаны поддерживать его работоспособность как минимум на текущей ветке системы, то есть если сервис внес изменения в запросы, формат запроса или ответа - доступ к таким изменениям должны иметь все ваши клиенты, вне зависимости, оплачены у них обновления или нет.
Потому что это не обновления системы, это - восстановление работоспособности.


#6

Я писал про это 3 года назад

Еще один момент это собственно сами обновления. Мы за последние 2,5 года приложили много усилий, чтобы обновления перестали быть болью. Внедрили SP, документацию для разработчиков, возможность быстро откатывать изменения по ссылке. Версионирование, когда при обновлении на патч версию (изменение последней цифры) вы понимаете что вероятность проблем минимальна.
Нам нужно чтобы максимальное количество людей было на последних версиях, потому что очень много времени уходит не только у техподдеркжи но и у разработки на адаптирование багофиксов, изучение проблем на старых версиях. Чем больше людей на последних версиях тем быстрее мы движемся вперед.

А еще вот здесь: Яндекс.Маркет для магазинов: модель DBS
Но там вы были заняты другим.

@z.temerbekov вот тут был иная мысль))


#7

Чуть позже это изучу отпишусь.


#8

на бумаге всё, конечно, красиво…
а на деле, как я уже и написал. Ну, думаю, вот оно, обновлюсь, теперь то всё исправили. А зайду на форум, и читаю, что еще одна важная плюшка сломана. Сейчас или раньше - неважно. Кстати - исправить ее вы можете и как раз в минорной версии - там тоже много фиксов присутствует. И как раз об этом пост выше. Чтобы например минор, содержащий патчи/новые_плюшки разделить на сначала следующую цифру после второй точки только с патчами и фиксами, и можно следом сразу минор с только плюшками. Тогда будет выбор: обновиться только на последний SP в этом миноре, или сразу идти на следующий минор


#9

Уже давно придерживаюсь мнения “Работает? Не трогай!” и обновляюсь через пару недель


#10

два с половиной года уже не трогаю, хотя и хочется


#11

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

Но когда я писал про stable версию, я на самом деле не противоречу себе. Я говорю что вам надо выпускать все те же быстрые патчи, чтобы стабилизировать продукт или вывести базовые функционал в реалии которые отвечают современному рынку икомерс.


#12

Теперь Вы невнимательно прочитали мною написанное.

то есть если вы выпускаете версию с измененным вторым числом, то есть с изменением или добавлением функционала - сейчас в ЭТОМ же обновлении включены и накопившиеся исправления, так вот я предложил исправления ВСЕГДА выпускать отдельно от изменений функционала, фактически разведя по отдельности исправления и изменения. И при переходе нвпример 4.24.125 - 4.25.1 выпустить не сразу 4.25.1, а 4.24.125 - 4.24.125SP1 - 4.25.1. Чтобы иметь поотдельности версию 4.24.125SP1 со всеми возможными фиксами ветки 4.24, и отдельно 4.25 - для проб и тестов, и возможно перехода, если в конкретном случае критичных багов не будет обнаружено.


#13

Понял вас, спасибо. Теоретически вплоть до 50-60% фиксов мы можем включать в отдельный патч релиз, который выпускаем перед минорным. Тут обратная сторона только время. Т.е. подготовка релиза процесс трудоемкий, и получается подготовка в параллель двух версий это вплоть до недели времени.

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

Попробуем в ближайшее время запустить опрос среди клиентов и среди разработчиков.