On 2/28/17, Warren Young <war...@etr-usa.com> wrote: > >> Then after a month or so we can release Fossil 2.1, in which all new >> content is always SHA3. > > If there’s going to be a transition time, I think it would need to be > something like a year or two, during which both Fossil 1 and Fossil 2 are > actively maintained.
A year or two? Seriously? Since sending the previous, I've reconsidered and would now like to release Fossil 2.0 and Fossil 2.1 simultaneously. The only difference between these two version will be that Fossil 2.0 still always generates SHA1 hashes on new content whereas Fossil 2.1 generates only SHA3 hashes. But both version understand SHA3 hashes. Notice the subtle change in Fossil 2.0. Instead of generating either SHA1 or SHA3 hashes depending on what it has seen before, 2.0 now always generates only SHA1 hashes. Unconditionally. By releasing both versions simultaneously, organizations can upgrade according to their own schedule. First they deploy Fossil 2.0. While that deployment is going on, Fossil 2.0 will interoperate seamlessly with legacy Fossil 1.x instances. Once everybody in the organization is safely on 2.0, then start rolling out Fossil 2.1. No SHA3 content is injected until the beginning of the 2.1 rollout, but by then everybody is on at least 2.0 and can easily handle the SHA3 content. Still an open question: Should the SHA3 hashes be SHA3-224 or SHA3-256? In my view, the extra computation and storage overhead for SHA3-256 is minimal and should not present a barrier. However, the extra 8 characters of hash from SHA3-256 do seem to introduce UI challenges. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
