Это не регрессия, а намеренное изменение. Решение о том ставить ли точку теперь за пользователем.

А по каким причинам не хочется ставить точки в конце предложений? Записи в changelog - это именно предложения, в конце предложений принято ставить точку.
В commit message же - это заголовок, там точка не нужна.

> А по каким причинам не хочется ставить точки в конце предложений?

1. Потому что появились пользователи, которые хотят иметь другое форматирование.
2. Потому что из-за этого пустая строчка становится непустой.

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

(В ответ на комментарий №4)
> Тогда я думаю это должно быть настраиваемое поведение, очень напрягает
> расставлять теперь точки вручную.

Сейчас ставить точку или нет решает пользователь. Раньше она ставилась всегда принудительно и убрать её было нельзя.

> И ставить точку - быть значением по умолчанию, я думаю это чаще нужно.

Это вкусовщина.

(In reply to comment #5)
> (В ответ на комментарий №4)
> > Тогда я думаю это должно быть настраиваемое поведение, очень напрягает
> > расставлять теперь точки вручную.
> 
> Сейчас ставить точку или нет решает пользователь.

А какие у пользователя есть возможности настройки этого поведения?

(В ответ на комментарий №6)
> А какие у пользователя есть возможности настройки этого поведения?

Добавить в группу:

filter: s/^.*/&./

или поставить точку в уже существующем фильтре, если он есть.

А глобально это как-то можно сделать? Не писать же такие правила для каждого своего gear-репозитория.

(В ответ на комментарий №8)
> А глобально это как-то можно сделать? Не писать же такие правила для каждого
> своего gear-репозитория.

Постойте, а как вы используете эту утилиту ?

Она задумывалась как агригатор, который работает с правилами, иначе gear-changelog ни чем не отпличается "git log --format='- %s (by %an).'". У меня везде, где я её использую есть правила. Поэтому мне не казалось неправильным перенос точки в правила.

(In reply to comment #9)
> (В ответ на комментарий №8)
> > А глобально это как-то можно сделать? Не писать же такие правила для каждого
> > своего gear-репозитория.
> 
> Постойте, а как вы используете эту утилиту ?
> 
> Она задумывалась как агригатор, который работает с правилами, иначе
> gear-changelog ни чем не отпличается "git log --format='- %s (by %an).'". У
> меня везде, где я её использую есть правила. Поэтому мне не казалось
> неправильным перенос точки в правила.

Ну, у меня скрипт использует gear-changelog --no-rules и добавляет в spec этакий полуфабрикат, из которого обычно нужно удалить лишнее. Он далеко не всегда делает то, что мне надо, конечно, но это все же лучше, чем просто git log --format: gear-changelog делает заголовок для %changelog и изменения берет только с последнего тэга.
Я могу свои скрипты написать, но раз есть gear-changelog, то хотелось бы использовать его.

(В ответ на комментарий №10)
> Ну, у меня скрипт использует gear-changelog --no-rules и добавляет в spec
> этакий полуфабрикат, из которого обычно нужно удалить лишнее. Он далеко не
> всегда делает то, что мне надо, конечно, но это все же лучше, чем просто git
> log --format: gear-changelog делает заголовок для %changelog и изменения берет
> только с последнего тэга.

Интересный usecase.

> Я могу свои скрипты написать, но раз есть gear-changelog, то хотелось бы
> использовать его.

А что он должен уметь делать, чтобы вам было удобно ?

(In reply to comment #11)
> А что он должен уметь делать, чтобы вам было удобно ?

Получается, что 2 взаимоисключающих вещи: если я мержу новый апстримный релиз (обычно тэг), то очевидно, мне хочется видеть в changelog только изменения из моего текущего бранча с последней сборки (т.е. с предыдущего тэга), все коммиты же апстрима мне в качестве записей в changelog совсем не нужны. Сейчас они все попадают в changеlog и их приходится вычищать.
Если же я мержу апсримный бранч между релизами и решаю, что это будет отображено в changelog как отдельные патчи из апстрима, то мне удобно иметь там записи для апстримных коммитов. То же самое когда мержится чей-то еще бранч с изменениями.
Т.е. для одного и того же гит-репозитория в разные моменты хочется разного поведения. Хотя если правила будут позволять задать нужное поведение, то можно использовать --rules для разных правил, видимо. Тем более, что такие правила скорее всего будут одинаковые для разных репо и нет никакого смысла их дублировать для каждого.

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

Кроме того, работа без правил это не то, чего я хотел. С помощью правил я группирую, фильтрую и форматирую записи. Именно поэтому дополнительное форматирование (типа точек в конце) мешает.

Не думаю, что это нужно исправлять.