
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/30/12 06:33, Stefan Roese wrote:
Hi Wolfgang,
On 10/30/2012 12:05 PM, Wolfgang Denk wrote:
[snip]
- Versioning is done on a per-series base.
One problem here is that it becomes difficult to keep track if what is what when only single patches of the series change and get reposted - on the other hand it has always been a major PITA when people repost whole series after only changing a line of two in on of their many patches, so we strongly encourage posting of only the changed patches. Once more, proper threading appears to be essential.
Another problem is what we are running into here: after severl versions of the patch series one patch that has been untouches previously gets changed. Now it gets posted as "V6", and it's impossible to know how many previous versions of this patch might have been posted before - one? 2? 3? 4? or 5?
When the version ID refers to the patch series rather than to the individual patch, then I think it is mandatory to take this into consideration in the patch history, whih then must refer to all versions of the _series_. In the present case, the patch history should have looked like this:
V2: no changes V3: no changes V4: no changes V5: no changes V6: Fix compile warning: release.S:354:0: warning: "EPAPR_MAGIC" redefined
Is there any clear majority of preferences for patch versioning? My gut feeling is that more people would like version IDs on a per-series base, but I would like to see some confirmation for this, and the we should document such expectations.
As you have already guessed, I'm in favoring the 2nd option, versioning on a per-series base.
What do other developers have to say? What's the recommended way to do this in the Linux world? Even if we don't need to do everything in the same way as done in Linux development, it is much easier to do it in a similar fashion for users working in both projects (U-Boot & Linux) regularly.
So, I am in favor of per-series versioning. I also prefer whole reposting (which I believe to be the norm in the kernel) with a dash of common sense (posting just 1/7 makes sense here) due to how patchwork bundles work.
- -- Tom