Replies: 11 comments
-
proposal A.1Relevant changes to the vandamme specification:
|
Beta Was this translation helpful? Give feedback.
-
@mockturtl great summary! Thanks!
What the reason for this point?
Why this form? I don't see a lot change logs, the use this convention. |
Beta Was this translation helpful? Give feedback.
-
Well: that's a good question. I will speculate it's because of the regex their parser happens to use (equivalently, an assumption of "semver-like" version strings). It's my understanding golang, for example, prefers monotonic integer releases. So I don't immediately see a good reason to defend this clause; let's strike it. proposal A.2
Only because there's an existing specification to discuss, and it's simple. Loosening the constraint to hyphens, whitespace, parens, italics, ... does not seem harmful, but I don't see an advantage. (Personally, I prefer no dates -- they can be recovered from git, and I don't think they add value.) |
Beta Was this translation helpful? Give feedback.
-
Not every project is open-source and, even then, not all users know how to use Git or have the time to learn. Putting the date in the change log, which is generally distributed with the binary release, allows users to find out when a release was made and see how out of date they are. |
Beta Was this translation helpful? Give feedback.
-
The counter-argument is that nontechnical users want "latest," and will not read a changelog. (I just opined on issue 44: the proper audience of this document is engineers. Contrast, release notes.) But we're just discussing my personal preference; I should probably not have mentioned it in this context. |
Beta Was this translation helpful? Give feedback.
-
Agree that dates are critical information in a change log. |
Beta Was this translation helpful? Give feedback.
-
As I mention above - 90% use I agree with @elyscape, @mockturtl: |
Beta Was this translation helpful? Give feedback.
-
I also agree that the date should be a supported, albeit optional, part of a change log spec definition. When I said "critical" I meant that they are "critically useful" to what I use change logs for in my regular development work. |
Beta Was this translation helpful? Give feedback.
-
The guiding principle should be the simplest thing that could work. Favoring GitHub popularity could yield a mashup of, say, Google's style guides. We're bikeshedding, now, but I think vandamme got it right: From your examples: notice h5bp contradicts this proposal re: English dates. Angular contradicts it re: h1 headers. |
Beta Was this translation helpful? Give feedback.
-
Picasso's date is italic, and tags include the string
proposal B
|
Beta Was this translation helpful? Give feedback.
-
Personally, I advocate the use of the format This produces a visually more easy way to process the headings as a human reader, as it is a fixed format string followed by a variably format string. |
Beta Was this translation helpful? Give feedback.
-
Hi. I'm developing related project Github-Changelog-Generator.
And has a question - what will be guideline for date wrapping format.
For example: in that project format like
tag - date
I try to research, how people usually print date and here is a some stats:
tag (date)
tag - date
Examples:
So, I would like to discuss, what should be guideline for changelog format and why?
Beta Was this translation helpful? Give feedback.
All reactions