| 1 |
On Thu, 2013-09-26 at 06:02 -0600, EBo wrote: |
| 2 |
> it is not an issue with it being hard, but stability and consistency -- |
| 3 |
> the code that I am you checked out of a repository and built last week |
| 4 |
> is not necessarily the same code I checked out and emerged today. |
| 5 |
> Someone might have made a change the day before yesterday which |
| 6 |
> introduced a bug, and when I post a bug report there is no way to know |
| 7 |
> what code either of us are compiling. |
| 8 |
> |
| 9 |
> I always preferred using date-stamped ebuilds which check out a |
| 10 |
> particular revision of a code base. So I know that on 20130923 this is |
| 11 |
> when I tested revision #219 with a hashtag of "fa1f0b5c4db5". Then when |
| 12 |
> I go back to test or depend on something, I know exactly what version we |
| 13 |
> are talking about. |
| 14 |
|
| 15 |
> Best regards, |
| 16 |
> |
| 17 |
> EBo -- |
| 18 |
> |
| 19 |
> |
| 20 |
|
| 21 |
FYI layman-9999 uses the git revision in the version, so submitting a |
| 22 |
bug can be very specific about the version it occurred in. It also |
| 23 |
helps me to track down a possible regression. But for dependency use, |
| 24 |
yeah, date versions are better. |
| 25 |
-- |
| 26 |
Brian Dolbec <dolsen@g.o> |
Archives