doc: Remove obsolete CHANGES-staging and UPGRADE-staging
This commit is contained in:
George Joseph
parent
c35471ad10
commit
9b3abda528
|
|
@ -1,37 +0,0 @@
|
|||
## **DO NOT REMOVE THIS FILE!**
|
||||
|
||||
The only files that should be added to this directory are ones that will be
|
||||
used by the release script to update the CHANGES file automatically. The only
|
||||
time that it is necessary to add something to the CHANGES-staging directory is
|
||||
if you are either adding a new feature to Asterisk or adding new functionality
|
||||
to an existing feature. The file does not need to have a meaningful name, but
|
||||
it probably should. If there are multiple items that need documenting, you can
|
||||
add multiple files, each with their own description. If the message is going to
|
||||
be the same for each subject, then you can add multiple subject headers to one
|
||||
file. The "Subject: xxx" line is case sensitive! For example, if you are making
|
||||
a change to PJSIP, then you might add the file "res_pjsip_my_cool_feature.txt" to
|
||||
this directory, with a short description of what it does. The files must have
|
||||
the ".txt" suffix. If you are adding multiple entries, they should be done in
|
||||
the same commit to avoid merge conflicts. Here's an example:
|
||||
|
||||
> Subject: res_pjsip
|
||||
> Subject: Core
|
||||
>
|
||||
> Here's a pretty good description of my new feature that explains exactly what
|
||||
> it does and how to use it.
|
||||
|
||||
Here's a master-only example:
|
||||
|
||||
> Subject: res_ari
|
||||
> Master-Only: True
|
||||
>
|
||||
> This change will only go into the master branch. The "Master-Only" header
|
||||
> will never be in a change not in master.
|
||||
|
||||
Note that the second subject has another header: "Master-Only". Changes that go
|
||||
into the master branch and ONLY the master branch are the only ones that should
|
||||
have this header. Also, the value can only be "true" or "True". The
|
||||
"Master-Only" part of the header IS case-sensitive, however!
|
||||
|
||||
For more information, check out the wiki page:
|
||||
https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Subject: app_senddtmf
|
||||
|
||||
The SendFlash AMI action now allows sending
|
||||
a hook flash event on a channel.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
Subject: app_mixmonitor
|
||||
Subject: audiohook
|
||||
Subject: manager
|
||||
|
||||
It is now possible to specify the MixMonitorID when calling
|
||||
the manager action: MixMonitorMute. This will allow an
|
||||
individual MixMonitor instance to be muted via ID.
|
||||
|
||||
The MixMonitorID can be stored as a channel variable using
|
||||
the 'i' MixMonitor option and is returned upon creation if
|
||||
this option is used.
|
||||
|
||||
As part of this change, if no MixMonitorID is specified in
|
||||
the manager action MixMonitorMute, Asterisk will set the mute
|
||||
flag on all MixMonitor audiohooks on the channel. Previous
|
||||
behavior would set the flag on the first MixMonitor audiohook
|
||||
found.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
Subject: bridge_builtin_features
|
||||
|
||||
Add optional touch variable : TOUCH_MIXMONITOR_BEEP(interval)
|
||||
|
||||
Setting TOUCH_MIXMONITOR_BEEP/TOUCH_MONITOR_BEEP to a valid
|
||||
interval in seconds will result in a periodic beep being
|
||||
played to the monitored channel upon MixMontior/Monitor
|
||||
feature start.
|
||||
|
||||
If an interval less than 5 seconds is specified, the interval
|
||||
will default to 5 seconds. If the value is set to an invalid
|
||||
interval, the default of 15 seconds will be used.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
Subject: cli
|
||||
Subject: core
|
||||
|
||||
This change increases the display width on 'core show channels'
|
||||
amd 'core show channels verbose'
|
||||
|
||||
For 'core show channels', the Channel name field is increased to
|
||||
64 characters and the Location name field is increased to 32
|
||||
characters.
|
||||
|
||||
For 'core show channels verbose', the Channel name field is
|
||||
increased to 80 characters, the Context is increased to 24
|
||||
characters and the Extension is increased to 24 characters.
|
||||
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Subject: DUNDi
|
||||
|
||||
DUNDi now supports chan_pjsip. Outgoing calls using
|
||||
PJSIP require the pjsip_outgoing_endpoint option
|
||||
to be set in dundi.conf.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Subject: format_sln
|
||||
|
||||
format_sln now recognizes '.slin' as a valid
|
||||
file extension in addition to the existing
|
||||
'.sln' and '.raw'.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
Subject: res_http_media_cache
|
||||
|
||||
The res_http_media_cache module now attempts to load
|
||||
configuration from the res_http_media_cache.conf file.
|
||||
The following options were added:
|
||||
* timeout_secs
|
||||
* user_agent
|
||||
* follow_location
|
||||
* max_redirects
|
||||
* protocols
|
||||
* redirect_protocols
|
||||
* dns_cache_timeout_secs
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
Subject: test.c
|
||||
|
||||
The "tests" attribute of the "testsuite" element in the
|
||||
output XML now reflects only the tests actually requested
|
||||
to be executed instead of all the tests registered.
|
||||
|
||||
The "failures" attribute was added to the "testsuite"
|
||||
element.
|
||||
|
||||
Also added two new unit tests that just pass and fail
|
||||
to be used for testing CI itself.
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
## **DO NOT REMOVE THIS FILE!**
|
||||
|
||||
The only files that should be added to this directory are ones that will be
|
||||
used by the release script to update the UPGRADE.txt file automatically. The
|
||||
only time that it is necessary to add something to the UPGRADE-staging directory
|
||||
is if you are making a breaking change to an existing feature in Asterisk. The
|
||||
file does not need to have a meaningful name, but it probably should. If there
|
||||
are multiple items that need documenting, you can add multiple files, each with
|
||||
their own description. If the message is going to be the same for each subject,
|
||||
then you can add multiple subject headers to one file. The "Subject: xxx" line
|
||||
is case sensitive! For example, if you are making a change to PJSIP, then you
|
||||
might add the file "res_pjsip_my_cool_feature.txt" to this directory, with a
|
||||
short description of what it does. The files must have the ".txt" suffix.
|
||||
If you are adding multiple entries, they should be done in the same commit
|
||||
to avoid merge conflicts. Here's an example:
|
||||
|
||||
> Subject: res_pjsip
|
||||
> Subject: Core
|
||||
>
|
||||
> Here's a pretty good description of my new feature that explains exactly what
|
||||
> it does and how to use it.
|
||||
|
||||
Here's a master-only example:
|
||||
|
||||
> Subject: res_ari
|
||||
> Master-Only: True
|
||||
>
|
||||
> This change will only go into the master branch. The "Master-Only" header
|
||||
> will never be in a change not in master.
|
||||
|
||||
Note that the second subject has another header: "Master-Only". Changes that go
|
||||
into the master branch and ONLY the master branch are the only ones that should
|
||||
have this header. Also, the value can only be "true" or "True". The
|
||||
"Master-Only" part of the header IS case-sensitive, however!
|
||||
|
||||
For more information, check out the wiki page:
|
||||
https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt
|
||||
Loading…
Reference in New Issue