A release note, derived from the commits between two published versions. Pure.
The single definition of what a hive release note IS. Two projections read it: the CHANGELOG.md this library generates at release time, and the note hive-store shows a subscriber. Neither authors it, so neither can disagree with the other or with git.
It can be derived at all because two facts already hold:
<scm><tag>What a READER is shown is not the whole log. A range of sixty commits is typically half housekeeping, and printing it all buries the seventeen fixes among thirty dependency bumps. The kinds a reader deciding whether to bump cares about are published; the rest are counted.
A release note, derived from the commits between two published versions. Pure. The single definition of what a hive release note IS. Two projections read it: the CHANGELOG.md this library generates at release time, and the note hive-store shows a subscriber. Neither authors it, so neither can disagree with the other or with git. It can be derived at all because two facts already hold: - a hive version names exactly one commit, through its tag - every published pom records that commit in `<scm><tag>` What a READER is shown is not the whole log. A range of sixty commits is typically half housekeeping, and printing it all buries the seventeen fixes among thirty dependency bumps. The kinds a reader deciding whether to bump cares about are published; the rest are counted.
(breaking-footer? message)Whether message declares a break in its body the way the convention says.
A ! in the subject is the short spelling and is read separately. This is
the long one, and a commit that uses only the footer would otherwise be
published as an ordinary feature.
Whether `message` declares a break in its body the way the convention says. A `!` in the subject is the short spelling and is read separately. This is the long one, and a commit that uses only the footer would otherwise be published as an ordinary feature.
(commit message)One commit message as a parsed note entry, or nil when it is not a conventional commit.
nil rather than a bucket for unrecognised subjects: they are counted by the caller, and inventing a kind for them would put an arbitrary heading over somebody's prose.
One commit message as a parsed note entry, or nil when it is not a conventional commit. nil rather than a bucket for unrecognised subjects: they are counted by the caller, and inventing a kind for them would put an arbitrary heading over somebody's prose.
Types that are real work and are not news to somebody outside the repo.
Counted rather than dropped: a range with forty of these and no feature is itself worth seeing, and reporting zero commits for it would be a lie.
Types that are real work and are not news to somebody outside the repo. Counted rather than dropped: a range with forty of these and no feature is itself worth seeing, and reporting zero commits for it would be a lie.
(newsworthy? note)Whether this note has anything in it a reader would read.
A range of pure housekeeping is a real answer and is drawn as one, but it is not a headline, and a page can use this to decide which of the two it is looking at.
Whether this note has anything in it a reader would read. A range of pure housekeeping is a real answer and is drawn as one, but it is not a headline, and a page can use this to decide which of the two it is looking at.
(of-commits messages)The commits between two releases, as the note a reader reads.
:note/sections are the published kinds that have anything in them, in
reading order. :note/breaking lifts every breaking change to the top
whatever its kind, because a reader deciding whether to bump has exactly one
question that outranks the rest.
:note/routine counts the housekeeping and :note/unconventional the
subjects that follow no convention. Both are numbers rather than lists, and
both are reported: a range that is entirely dependency bumps must look like
one rather than like an empty release.
The commits between two releases, as the note a reader reads. `:note/sections` are the published kinds that have anything in them, in reading order. `:note/breaking` lifts every breaking change to the top whatever its kind, because a reader deciding whether to bump has exactly one question that outranks the rest. `:note/routine` counts the housekeeping and `:note/unconventional` the subjects that follow no convention. Both are numbers rather than lists, and both are reported: a range that is entirely dependency bumps must look like one rather than like an empty release.
The conventional-commit types a release note shows, in reading order, and the heading each becomes.
Ordered by what a reader deciding whether to bump wants first: what is new, what is fixed, what got faster, what moved. The headings are Keep a Changelog 1.1.0 headings, so the same value renders as a changelog section.
The conventional-commit types a release note shows, in reading order, and the heading each becomes. Ordered by what a reader deciding whether to bump wants first: what is new, what is fixed, what got faster, what moved. The headings are Keep a Changelog 1.1.0 headings, so the same value renders as a changelog section.
(subject-of message)The first line of a commit message.
The first line of a commit message.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |