1 |
Aron Griffis wrote: |
2 |
> I just updated gentoolkit to version 0.1.21. This version includes two |
3 |
> changes: |
4 |
> |
5 |
> 1. echangelog now follows the older, sanctioned format for the |
6 |
> ChangeLog. This means that all new entries are added at the top. A |
7 |
> new version or revision will cause a new *version string. |
8 |
|
9 |
I don't think this is appropriate for -dev, but since you |
10 |
started it here, I'm going to comment. Why are you doing |
11 |
this? Sanctioned or not, the "old" way was never enforced, |
12 |
and not clearly stated as policy in the developer's |
13 |
handbook. Also, many prefer the new way. Let's consider this: |
14 |
|
15 |
Old Way: |
16 |
Changes were spread all willy-nilly over the Changelog in |
17 |
chronological order. There was no organization other then |
18 |
that, so it was often difficult to isolate which specific |
19 |
revision was changed at a glance and when. This, obviously, |
20 |
doesn't scale well when we start getting changelogs with |
21 |
100+ entries |
22 |
|
23 |
New Way: |
24 |
Changes are still in chronological order, but they are |
25 |
indexed under each specific ebuild preceded by the star. |
26 |
that means, if I want to know what's changed to what |
27 |
version, I can quickly scan the *'ed entries for the |
28 |
revision I want and there you go. As for finding out |
29 |
overall what's changed in the last few days, that is also |
30 |
just as easy as before. I'd merely scan the the top portion |
31 |
of each revision. This method scales much better and keeps |
32 |
Changelog entries neat and orderly, even when faced with |
33 |
100+ entries. |
34 |
|
35 |
So, for the time being, can we put echangelog back to the |
36 |
way it was until this is further discussed? |
37 |
|
38 |
Comments welcomed. |
39 |
|
40 |
Cheers, |
41 |
Nicholas |
42 |
|
43 |
|
44 |
-- |
45 |
gentoo-dev@g.o mailing list |