1 |
Hi all! |
2 |
|
3 |
Right now we have two somewhat conflicting policies (at least up to |
4 |
my understanding of them): |
5 |
|
6 |
1) git atomic commits [1]: |
7 |
each logical change should be a separate commit. |
8 |
|
9 |
2) revision bump policy [2]: |
10 |
each change sufficiently affecting application run-time or |
11 |
installed files should have a revision bump. |
12 |
|
13 |
Let's consider the following quite common scenario: package foo-1.0 |
14 |
should be updated to foo-1.1, but aside from version bump there is |
15 |
a set of accumulated issues which maintainer is willing to handle, |
16 |
e.g.: |
17 |
- bump to EAPI 6; |
18 |
- fix several runtime bugs (still present in the new version); |
19 |
- install missing documentation; |
20 |
- add previously omitted USE flags for some tools of controllable |
21 |
functionalities; |
22 |
- etc... |
23 |
|
24 |
If both policies are to be followed, users will see something like: |
25 |
foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as |
26 |
a separate commit with a revision bump). |
27 |
|
28 |
While such versioning change is technically correct, it is |
29 |
confusing for our users and makes future maintainance harder, |
30 |
because of multiple file renames (yeah, I know about git diff |
31 |
--find-renames, but this kludge is not perfect). |
32 |
|
33 |
What about the following forkflow: |
34 |
- version bump first with minimal changes required, but without |
35 |
pushing commit to the tree; |
36 |
- make each logical change as a separate commit without revision |
37 |
bumps and without pushing stuff to the tree (of course repoman |
38 |
scan/full is required as usual for each commit); |
39 |
- well test package after the last commit (that it builds with |
40 |
various USE flag combinations, old and new functionality works fine |
41 |
and so on); |
42 |
- fix any problems found and only afterwards push changes to the |
43 |
tree. |
44 |
|
45 |
This way users will see only foo-1.0 -> foo-1.1 change in the tree, |
46 |
while git will still retain each logical change as a separate |
47 |
commit, which will make future maintenance and debugging much |
48 |
easier. |
49 |
|
50 |
Of course a separate git branch may be used as well, but using |
51 |
branches for each half-a-dozen set of commits looks like an |
52 |
overkill to me. |
53 |
|
54 |
Thoughts, comments? |
55 |
|
56 |
[1] https://devmanual.gentoo.org/ebuild-maintenance/index.html |
57 |
[2] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html |
58 |
|
59 |
Best regards, |
60 |
Andrew Savchenko |