| 1 |
On 12/02/2016 10:14 AM, Andrew Savchenko wrote: |
| 2 |
> |
| 3 |
> If both policies are to be followed, users will see something like: |
| 4 |
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as |
| 5 |
> a separate commit with a revision bump). |
| 6 |
> |
| 7 |
> While such versioning change is technically correct, it is |
| 8 |
> confusing for our users and makes future maintainance harder, |
| 9 |
> because of multiple file renames (yeah, I know about git diff |
| 10 |
> --find-renames, but this kludge is not perfect). |
| 11 |
|
| 12 |
Do you have a situation in mind where going from -r0 to -r8 in one `git |
| 13 |
push` is a problem? What maintenance becomes harder? I can see how it |
| 14 |
could be confusing, but only in the sense that we've been doing it wrong |
| 15 |
for so long that now it's surprising to see it done right. Now it makes |
| 16 |
sense: the -r8 version contains 8 more fixes than -r0. |
| 17 |
|
| 18 |
I should be able to `git checkout` any commit in the repo and have the |
| 19 |
tree not be broken. Your proposal eliminates that guarantee, and the bar |
| 20 |
for doing so should be high, I think. |
Archives