Added a comment: comment regarding "default" version of the repo etc

diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment
new file mode 100644 (file)
index 0000000..187116d
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment regarding "default" version of the repo etc"
+ date="2022-01-26T18:40:50Z"
+ content="""
+> I think you are making this a lot more complex than it will appear to any user. These versions are almost indistinguishable by the user; v9 is literally one git config change from v8.
+
+well, to me as a user those upgrades become immediately visible whenever older (not yet supporting v9) version of git-annex tries to operate on v9 repository (regardless how trivial the change between 8 and 9 is).
+
+I recommended adding explicit \"default\" primarily because you cited man pages as the operational/design guide, and I felt that it is incomplete.
+
+> I suspect your test suite is unncessarily fragile around git-annex repository version numbers, perhaps that is the real root of your problem?
+
+might be... although I can proudly state that may be not -- we had only 2 (out of many 100s) tests failing, so at least that check seems to be quite nicely isolated in our tests.  And insofar seems have pointed to a defect in git-annex (they are all back to green, woohoo! ;) ). Having stated that -- we might indeed want to adjust them.
+
+"""]]