This is what happened as I understand it: The codename "fossil 2.0" has been used for a few years whenever a change that would potentially break backwards compatibility was suggested. Such a version, if ever released, would require more planning, more testing and more notice to users then a "regular" cycle release. Since the SHA1 issue caught everyone by surprise (side note: Why were we all caught by surprise when this was known to be theoretically possible for over a decade?), there was an urgent need to fix this issue, which would break backwards compatibility. So "fossil 2.0" happened in a rush, without time to track down and implement all the issues waiting for "fossil 2.0".
-- END HISTORY LESSON -- That being said, time for my suggestion: Since version 2.0 ended up NOT breaking anything, and the breaking changes will be in 2.1 and 2.2, maybe we can still change some of the things that were waiting for a "breaking" release in 2.1 or 2.2? Since the SHA1 issue will not really be fixed until version 2.1, but version 2.2 will still be breaking some backwards compatibility (pushing from a pre-2.1 client will not be possible) , how about releasing 2.1 with only a note in the release notes that this will be the last version with behaviors X, Y and Z, and then take the time for 2.2 to actually implement/change what is needed? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
