On Feb 28, 2017, at 2:08 PM, Richard Hipp <d...@sqlite.org> wrote: > > 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?
That’s how we do it here. We have the development branch (trunk), the current stable branch, and the prior stable branch. Features added in development that don’t need to wait for the development branch to stabilize are backported to the current stable release immediately, and bug fixes are generally backported to at least the prior stable release. Very occasionally, we’re forced by circumstance to backport bug fixes three stable releases or more. Fossil supports all of that very nicely. So thank you. :) Sites currently on the prior stable release stay on the prior stable release until they’re formally upgraded. We didn’t invent that sort of scheme. You see it in RHEL, for example: RHEL 7 is almost 3 years old now, but RHEL 5 will still be in maintenance for another few months. > 2.0 now always generates only SHA1 hashes. Unconditionally. That’s one reason I suggest making 2.0 a long-term stable branch, for sites that refuse to upgrade everything to 2.x, but still want new features on the server at least. (As an example, the new /file feature in 1.37: only the server needs that for all clients to benefit. Thank you, by the way. It solves an actual problem I had here.) > Once everybody in the organization > is safely on 2.0, then start rolling out Fossil 2.1. That’s fine in smaller organizations where IT fiat works, but in large corporations with many divisions, organizational silos, and interdepartmental squabbles, getting everyone onto the same page is a battle in itself. Open source is even worse, because most users are silos until themselves. I’m not trying to twist your arm on this. I think it’s *also* fine if you just say “Fossil 1.37 is the last Fossil 1.x version” and be done with it. Those who insist on sticking with SHA-1 can use Fossil 1.37 as-is or fork it or whatever. _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
