>
> Isn't that the reason that the changes documentation is written in the
> first place...to warn users about upcoming changes? So an extra warning
> in the email would be redundant, and this warning would also fade into
> the background? (by the way, I don't think that comparatively a _lot_ of
>
>
> Do you think this isn't prominently enough? If so, how could this be
> improved?
>
I think that as with many warnings, the fact that it's always there leads
to it fading into the background for many readers, particularly as they
learn from experience that for *most* code, *most* of the time,
>> if you have reasonable ideas how such API changes could be
>> communicated better I am sure people would love to hear them and if
>> feasible incorporate them.
>
> IMO one relatively simple change would be to add a note to the release
> announcement email mentioning that users should expect to
Hi all,
I want to share a new feature I just pushed for lilypond-ts-mode: cycle
forward/backward through the same rhythmic position in all parts, even if
they are spread across multiple files. This is made possible by evaluating
LilyPond code within a Guile REPL using an engraver that outputs a l
>
> if you have reasonable ideas how such API changes could be
> communicated better I am sure people would love to hear them and if
> feasible
> incorporate them.
IMO one relatively simple change would be to add a note to the release
announcement email mentioning that users should expect to need
I assume this is directed at least in part toward me. Including thread
history below the reply is Gmail's built-in behavior. If there were a
setting to change that, I'd be more than happy to use it, but as far as I
know it's not possible to change that default. I can do my best to remember
to manua
On 2025-02-09 06:32, Valentin Petzel wrote:
the new property is there to allow for convert-ly to automatically make old
things work. I just do not fully understand why it is necessary and could not
simply be handled by adding a conversion function, e.g. turing something like
`...proportionalNota
It's not particularly my job to say this, but it needs to be said.
Certain people have not been keeping the tradition of the elders in
formatting replies to this list.
* Quote just enough of the message for your reply to be understood.
* Add your responses below the quoted text.
Please adapt.
AFAIK a normal user should see a warning for a deprecated property and an
error for an API break.
This is not the case: the user here sees a warning for an API break.
Fortunately, out of deliberate fussiness, I made sure that my test cases
already stop corresponding to warnings rather than just err
Hello Paolo,
> Given that, as Valentin noted, a new property has been introduced that
> allows code to be compiled with the old function, what is the point of
> exposing it to the user if it then corresponds to an API break?
> If it had been treated as a deprecated property I could have simply ign
>> proportionalNotationDuration is not deprecated. Its type has been
>> changed, therefore the warning about not accepting a moment is correct.
>
> that's what I was saying. Wouldn't it have been better to treat it
> as a deprecated property with an appropriate warning, rather than as
> an API b
that's what I was saying.
Wouldn't it have been better to treat it as a deprecated property with an
appropriate warning, rather than as an API break with a warning instead of
an error?
Given that, as Valentin noted, a new property has been introduced that
allows code to be compiled with the old fun
12 matches
Mail list logo
