Updating patch headers

Randy McMurchy randy at linuxfromscratch.org
Mon Jul 3 13:43:27 PDT 2006

Dan Nicholson wrote these words on 07/03/06 15:34 CST:

> Ah, yes, I'd forgotten about that.  Just for discussion though,
> suppose I'd submitted a patch and found out later some different info
> like Upstream Status and wanted to update it.  Should the patch
> version be bumped if just the header info has changed?

I would say yes. There is no harm in doing it, and anyone who
downloaded the previous one will know there is a revised patch.
(regardless how trivial) Even if just the header info has changed,
I would increment the version.

Seems petty, but look at it this way. Say someone downloaded the
-1 version and the origin field said "Unknown". Meanwhile you
updated the origin field and kept the version the same. The guy
who downloaded -1 thinks he has the current patch and spends time
revising and/or sending upstream. But it turns out it was already
upstream, but he didn't know that because he has an old patch,
and had no clue of knowing there was a newer one.

Remote, but possible. Why not take every bit of chance out of the
equation? My thoughts, anyway.

There was just a discussion about this in the last month or so.
Some (well, only one person) argued that we shouldn't increment
for trivial changes (or changes that occur just a few days after
the original was submitted). Tushar came into the discussion with
a very firm "the version should be incremented".

At least that is what I remember from the discussion.


rmlscsi: [bogomips 1003.27] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux i686]
15:35:00 up 52 days, 7:35, 1 user, load average: 0.12, 0.08, 0.03

More information about the blfs-dev mailing list