On 02/27/2017 11:43 AM, Warren Young wrote:
On Feb 26, 2017, at 1:45 PM, Richard Hipp <d...@sqlite.org> wrote:
(9) Can a Fossil 1.x client push/pull/clone from a Fossil 2.0 server,
assuming the repository uses SHA1 has it preferred hash algorithm?
This is desirable, but I am willing to sacrifice this capability in
order to reduce complexity.
Agreed as far as it goes, but consider how willing you’ll be to backport Fossil
2 features to Fossil 1 if you don’t design in this capability.
That is, if some non-hash-related feature lands in Fossil 2, and it solves a
given user’s problem, are you going to insist that they upgrade to Fossil 2 to
get it, or will you backport it to Fossil 1 to placate them?
It’s one thing to be stuck with a whole bunch of Fossil 1.29 clients used by
Debian Jessie users who refuse to use anything but what’s in the package repo.
It’s quite another to be unable to upgrade the servers as well because that’ll
break all the clients.
I'd favor breakage to know the data is secure with an updated hash.
I know things are backported to sqlite3, but only to premium members who
are supporting the project. Since Fossil doesn't operate like that, I
wouldn't want anyone's time wasted on pushing patches back to previous
versions and re-releasing them.
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
