#38 Changelogs: version-less entries exception
Closed: Fixed None Opened 13 years ago by nphilipp.

If E-V-R is left unchanged, i.e. no new version-release is built, a version-release-less changelog entry should be allowed (e.g. multiple changes without builds being queued up):

[https://fedoraproject.org/wiki/User:Nphilipp/Packaging/Changelogs_(draft)]

Mind that I'm on vacation between Dec 12th and Jan 23rd, I'm not available for questions then.


What's the change here? Just a few changes in the first sentence?

The change is addition of this: "... (the version-release component can be left out if no new packages are built, i.e. E-V-R is unchanged):", though I'm open for alternative wording.

Ah... I'd rather people just build up a single changelog entry over time. ie:

First commit, no build:

+* Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
+- Fix spelling errors in package description

Second commit and a build:
- Nov 12 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
+
Nov 13 2010 Toshio Kuratomi <toshio_fedoraproject.org> - 1.0-1
- Fix spelling errors in package description
+- Add a patch to fix compilation problems on F15

The rpm changelog is to help end users know at what package NEVR a change was introduced.

Heh, just lately I've been berated that RPM changelog entries are not suitable for end users and that I should fill out update notes in Bodhi. I am sure that people who can understand RPM changelog entries, can put intermediate (version-less) entries in the correct context as well: e.g. that if a change is made between versioned entries 1.0-1 and 1.0-2, that it's available from 1.0-2 on.

I really like having the date of the actual change in the changelog, even if it didn't result in an officially-built package -- it helps me keep things in context for me as well.

If you want to do that, it'd be much nicer for any tools to keep the versions:

  • Nov 13 2010 Blah - 1.0-1
  • Fix bar

  • Nov 12 2010 Blah - 1.0-1

  • Fix foo

...in this case it's "easy" for any code to work out what the version of the change was, for each entry. If you drop the V-R from the Nov. 12 entry, then while a human could mostly work it out ... no current code will.
But, personally, I'm with toshio ... it's better to have one entry (with one date), which is updated when a build happens.

Documenting both scenarios (multiple entries with the same V-R, appending additional items to existing V-R entry) approved (as opposed to permitting version-less changelog entries, which was not) - (+1:6, 0:0, -1:1)

Rathann has requested that his vote on this be changed from +1 to -1.

<Rathann|lappy> I looked at kernel changelogs and noticed multiple version-less entries between builds

Just FYI, I'll be on an extended vacation from tomorrow on, so I'll likely not be able to respond during that time -- but as I understand comment !#6 from Dec 1st the matter has been decided anyway...

If not, I still think version-less entries between builds are harmless as tools can easily skip over them when determining which changes belong to which build. Not only because tools can't rely on that they will only ever operate on packages from "clean" sources, simply assuming that no "malformed" entries will be encountered doesn't seem wise to me -- regardless of whether or not you consider version-less entries "malformed".

FESCo approved this on 2010-12-08.

Announce text:
A section has been added to the Packaging:Guidelines#Changelog entry describing the acceptable methods of having multiple changelog entries per release:

https://fedoraproject.org/wiki/Packaging:Guidelines#Multiple_Changelog_Entries_per_Release

(and it's going out today)

Metadata Update from @james:
- Issue assigned to spot

7 years ago

Login to comment on this ticket.

Metadata