mirror of
https://github.com/juce-framework/JUCE.git
synced 2026-01-14 00:14:18 +00:00
Updated the breaking changes document to reflect the previous commit that fixed a bug in Windows HTTPS connections
This commit is contained in:
parent
46a9da28d6
commit
a95ede0c6e
1 changed files with 20 additions and 3 deletions
|
|
@ -4,6 +4,23 @@ JUCE breaking changes
|
|||
Develop Branch
|
||||
==============
|
||||
|
||||
Change
|
||||
------
|
||||
Removed the setSecurityFlags() method from the Windows implementation of WebInputStream as it disabled HTTPS security features
|
||||
|
||||
Possible Issues
|
||||
---------------
|
||||
Any code previously relying on connections to insecure webpages succeeding will no longer work
|
||||
|
||||
Workaround
|
||||
----------
|
||||
Check network connectivity on Windows and re-write any code that relied on insecure connections
|
||||
|
||||
Rationale
|
||||
---------
|
||||
The previous behaviour resulted in network connections on Windows having all the HTTPS security features disabled, exposing users to network attacks. HTTPS connections on Windows are now secure and will fail when connecting to an insecure web address
|
||||
|
||||
|
||||
Change
|
||||
------
|
||||
Pointer arithmetic on a pointer will have the same result regardless if it is wrapped in JUCE's Atomic class or not
|
||||
|
|
@ -27,6 +44,7 @@ jassert (++a == ++b);
|
|||
Pointer a in the above code would be advanced by sizeof(int) whereas the JUCE's Atomic always advances it's underlying pointer by a single byte. The same is true for operator+=/operator-= and operator--. The difference in behaviour is confusing and unintuitive. Furthermore, this aligns JUCE's Atomic type with std::atomic.
|
||||
|
||||
|
||||
|
||||
Version 4.3.1
|
||||
=============
|
||||
|
||||
|
|
@ -68,7 +86,6 @@ Rationale
|
|||
A flawed multi-bus API was introduced with JUCE versions 4.0.0 up until version 4.2.4 (inclusive) which was not API compatible with pre JUCE 4 plug-ins. JUCE 4.3.0 releases a revised multi-bus API which restores pre JUCE 4 API compatibility. However, the new multi-bus API is not compatible with the flawed multi-bus API (JUCE version 4.0.0 - 4.2.4).
|
||||
|
||||
|
||||
|
||||
Change
|
||||
------
|
||||
JUCE now generates the AAX plug-in bus layout configuration id independent from the position as it appears in the Projucer’s legacy “Channel layout configuration” field.
|
||||
|
|
@ -87,9 +104,9 @@ The new multi-bus API offers more features, flexibility and accuracy in specifyi
|
|||
|
||||
|
||||
|
||||
|
||||
Version 4.2.1
|
||||
=============
|
||||
|
||||
Change
|
||||
------
|
||||
JUCE now uses the paramID property used in AudioProcessorParameterWithID to uniquely identify parameters to the host
|
||||
|
|
@ -105,4 +122,4 @@ Enable JUCE_FORCE_USE_LEGACY_IDS in the juce_audio_plugin_client module config p
|
|||
Rationale
|
||||
--------
|
||||
Each parameter of the AudioProcessor has an id associated so that the plug-in’s host can uniquely identify parameters. The id has a different data-type for different plug-in types (for example VST uses integers, AAX uses string identifiers). Before 4.2.1, JUCE generated the parameter id by using the index of the parameter, i.e. the first parameter had id zero, the second parameter had id one, etc. This caused problems for certain plug-in types where JUCE needs to add internal parameters to the plug-in (for example VST3 requires the bypass control to be a parameter - so JUCE automatically creates this parameter for you in the VST3 backend). This causes subtle problems if a parameter is added to an update of an already published plug-in. The new parameter’s id would be identical to the id of the bypass parameter in old versions of your plug-in, causing seemingly random plug-in bypass behaviour when user’s upgrade their plug-in.
|
||||
Most plug-in backends differentiate between a parameter’s id an index, so this distinction was adopted starting with JUCE 4.2.1 by deriving the parameter’s unique id from the paramID property of AudioProcessorParameterWithID class.
|
||||
Most plug-in backends differentiate between a parameter’s id an index, so this distinction was adopted starting with JUCE 4.2.1 by deriving the parameter’s unique id from the paramID property of AudioProcessorParameterWithID class.
|
||||
Loading…
Add table
Add a link
Reference in a new issue