| 1 |
On 07/25/2017 09:23 AM, Michał Górny wrote: |
| 2 |
> |
| 3 |
> How is that relevant? Revision bumps are merely a tool to encourage |
| 4 |
> 'automatic' rebuilds of packages during @world upgrade. I can't think of |
| 5 |
> a single use case where somebody would actually think it sane to |
| 6 |
> checkout one commit after another, and run @world upgrade in the middle |
| 7 |
> of it. |
| 8 |
> |
| 9 |
|
| 10 |
Revisions are to indicate that one incarnation of a package differs from |
| 11 |
another in a way that the user or package manager might care about. And |
| 12 |
on principal, it's no business of yours what people want to do with |
| 13 |
their tree. If someone wants to check out successive commits and emerge |
| 14 |
@world, he's within his rights to do so. |
| 15 |
|
| 16 |
This is relevant because your proposed policy, |
| 17 |
|
| 18 |
* presumes to know how people will use the tree, and places arbitrary |
| 19 |
restrictions on them |
| 20 |
|
| 21 |
* can cause problems if those assumptions don't hold |
| 22 |
|
| 23 |
* requires developers to think about when it's safe to push (Did I |
| 24 |
push those changes last night? Do I need another revision?) |
| 25 |
|
| 26 |
* and is more complicated than the safe solution, anyway |
| 27 |
|
| 28 |
Here's my proposal regarding revisions: |
| 29 |
|
| 30 |
If you make a commit that requires a revision, make a revision. |
| 31 |
|
| 32 |
If you wind up with an -r15 in the tree, who cares? It's simpler, safer, |
| 33 |
and less to think about. |
Archives