Stefan wrote on Sun, 17 Dec 2017 23:34 +0100:
> On 17/12/2017 23:12, Evgeny Kotkov wrote:
> > Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> >> This language implies that we made a backwards incompatible change in 1.6,
> >> which is not precisely the case; 1.6 simply started enforcing an API
> >> requirement that 1.5 did not.
> >> Could we perhaps rephrase this accordingly? I.e., point out that we weren't
> >> inventing a backwards-incompatible requirement, but starting to enforce one
> >> that had always been there?
> > I would think that from the standpoint of a user reading the release notes,
> > both versions look more or less the same (maybe, with the second one being
> > slightly harder to parse due to its verbosity):
> > Such property line endings were accepted by older servers and can be found
> > in repository dumps, but are considered invalid starting with Subversion 1.6.
> > Such invalid line endings were accepted by older servers and can be found
> > in repository dumps of older repositories, but are rejected by Subversion 1.6
> > and later.
> > But, presumably, both variants are fine, as both of them explain the reason
> > behind the "Cannot accept non-LF line endings" error — so please feel free
> > to commit this tweak if you think it would be more appropriate.
> > Thanks,
> > Evgeny Kotkov
> When reading the initial text, I was wondering exactly the point
> danielsh brought up. While to someone who is aware of the history, the
> how and why of the invalid line endings in a dump file is fully clear
> and he'd read both of the suggested descriptions absolutely the same (as
> you did, Evgeny); someone who doesn't know/recall the details might in
> fact wonder why the incompatibility behavior was introduced in 1.6 (as I
> did). That's less likely to happen with danielsh's phrasing, since it
> points out that these line endings were (always) considered invalid.
> So to not just reply here without taking action, I went ahead and
> committed danielsh's suggested change in r1818517.
Thanks, Stefan. As you say, preventing an impression that we make
incompatible changes in minor releases was precisely my goal.
As to the new language being more verbose, I don't see how to
shorten it without losing details; the "of older repositories" phrase
does add useful information, IMO.
Received on 2017-12-17 23:42:32 CET