| 1 |
On Mon, 08 Mar 2010 14:13:30 +0100 |
| 2 |
Róbert Čerňanský <hslists2@××××××.sk> wrote: |
| 3 |
|
| 4 |
> - Minor version bumps (After examination what upstream changed and |
| 5 |
> after confirmation with mantainer, if any.) |
| 6 |
|
| 7 |
The stuff you put in brackets is exactly the sort of stuff that |
| 8 |
tends to make version bumps hard to fix. |
| 9 |
|
| 10 |
You would first have to determine what major/minor means, on a per |
| 11 |
package-version basis, so these aren't really as trivial to fix as (non) |
| 12 |
package maintainer as a "minor version change" might suggest. |
| 13 |
|
| 14 |
Also, any version bump is a splendid occasion on which to revise the |
| 15 |
ebuild (introduce missing features, check for novel QA issues, move up |
| 16 |
an EAPI to cut out a few build phases, review COPYING to make sure |
| 17 |
the LICENSE variable is still OK, figure out that one slight syntax |
| 18 |
change might serve to fix a compilation error with a |
| 19 |
newer-toolchain-than-you-use). |
| 20 |
|
| 21 |
So I generally don't regard a version bump as a low hanging fruit, |
| 22 |
as you might end up painfully ignoring the wasps' nest hanging |
| 23 |
directly beside it. |
| 24 |
|
| 25 |
|
| 26 |
jer |
Archives