Управление версиями программ в зависимости от библиотеки

У меня есть набор программ, каждая со своей версией. Все эти программы зависят от библиотеки, опять же со своей версией. Например

Foo-1.0.3
Bar-2.1.5
Baz-1.3.4

Они зависят от libfrobniz-1.4.5. Бывает, что приходится делать капитальный ремонт библиотеки (с большим количеством рефакторинга). Это означает, что он сломает все (Фу, Бар и Баз). Конечно, поскольку это серьезная и обратно несовместимая переделка, библиотека будет увеличена до libfrobniz-2.0.0.

Мой вопрос касается версии Foo Bar и Baz. Я обновлю их, чтобы использовать libfrobniz-2.0.0, но не изменяю их функциональность. Новые версии этих трех программ можно использовать точно так же, как и старые, и поэтому они полностью совместимы. Однако они будут зависеть от совершенно другой версии libfrobniz. Не могли бы вы предложить увеличить их основной номер версии или просто уровень исправления?


versioning language-agnostic
person Stefano Borini    schedule 16.08.2009    source источник
comment
Не дурак. сообщение, которое вы предлагаете, говорит о конкретном стиле управления версиями. Прошу общих правил, с прицелом на мою конкретную проблему.   -  person Stefano Borini    schedule 17.08.2009
comment
@Stafano: хорошо, это может быть обман, но не обман того, что я опубликовал.   -  person John Saunders    schedule 17.08.2009
comment
Переработал вопрос для моей конкретной проблемы, что меня сейчас волнует.   -  person Stefano Borini    schedule 17.08.2009

Ответы (5)


arrow_upward
1
arrow_downward

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

person Draemon    schedule 16.08.2009
comment
Конечно, для конечных пользователей было бы серьезным изменением, если бы зависимые библиотеки предоставляли типы из измененной библиотеки. Может быть, нет, если ничего не выставлено? - person John Saunders; 17.08.2009
comment
Нет, ничего из libfrobniz не доступно конечному пользователю. - person Stefano Borini; 17.08.2009
comment
действительно изменение сродни рефакторингу. Я меняю только внутренности (внутренностями является вся библиотека), но ни одна из конечных функций программного обеспечения не затрагивается и не изменяется каким-либо образом. - person Stefano Borini; 17.08.2009

arrow_upward
1
arrow_downward

Я бы оставил номера версий Foo, Bar и Baz одинаковыми. Поскольку вы не вводите новые функции или исправления ошибок в эти продукты, предназначенные для пользователей, нет необходимости увеличивать номера версий. Кроме того, если вы решите изменить номера версий, это может вызвать путаницу у пользователей. Ваши пользователи могут задаться вопросом, почему ваши продукты имеют новый номер версии без каких-либо новых задокументированных функций или исправлений ошибок.

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

person zpesk    schedule 16.08.2009
comment
Если это разные банки, у них действительно должны быть разные номера версий, иначе, когда вы получите отчеты об ошибках, вы не будете знать, в каком потоке кода воспроизвести ошибку. - person Tom; 17.08.2009
comment
если бы вы различали номер версии для пользователя и номер версии libfrobniz, вы бы знали, какой поток кода использовать для воспроизведения потенциальных ошибок. - person zpesk; 17.08.2009

arrow_upward
0
arrow_downward

Ваша схема управления версиями зависит от вашего бизнеса и технических потребностей.

Некоторые компании выпускают «крупные» обновления каждый год, чтобы привлечь внимание и получить некоторый доход от обновлений. Некоторые из них до сих пор выпускают бета-версии, пока не устраивают качество ПО.

Подготовьте собственную схему и сообщите об этом своим клиентам. Обычно первая буква — это основной номер версии для основных изменений, затем для улучшений, а затем для сборок и исправлений.

person twk    schedule 16.08.2009

arrow_upward
0
arrow_downward

Разве это не то же самое, что создание 32-битной и 64-битной версии библиотеки? 32-битная зависит от 32-битных библиотек, а 64 зависит от 64-битных библиотек.

Следуйте правилам, которые вы бы использовали для чего-то подобного

person shimpossible    schedule 16.08.2009

arrow_upward
0
arrow_downward

«Конечно, поскольку это серьезная и обратно несовместимая переработка»,

Я помню время, когда у клиентов была возможность довести любого из своих поставщиков программного обеспечения до банкротства, если у этого поставщика программного обеспечения хватило наглости нарушить обратную совместимость, отказавшись тратить деньги до тех пор, пока обратная совместимость не будет восстановлена.

Поставщики программного обеспечения всегда уступали.

Сегодня кажется, что они могут делать все, что хотят, и каждый клиент будет просто бездумно следовать за ними, немного как люди низшего сословия из «1984».

Но, возможно, я излишне пессимистичен.

РЕДАКТИРОВАТЬ

Кто-то указал на случай, когда есть только один клиент, MySelf. В этом случае я бы не ожидал, что потребуется какая-либо «версионность». Такого покупателя интересует ровно одна вещь: чтобы программа работала, и интересует ровно одна единственная версия: та, которая предположительно соответствует его самым последним спецификациям.

person Erwin Smout    schedule 16.08.2009
comment
знаете, бывают случаи, когда у вас есть только один клиент, вы сами. - person Stefano Borini; 17.08.2009
comment
В ответ на ваше редактирование. Не совсем. Мне нужно управление версиями того, что я использую, потому что, если, скажем, через три года мне придется снова что-то пересчитывать, я должен знать, какую версию программного обеспечения я использовал для получения этого результата. - person Stefano Borini; 23.02.2010