mirror of
https://github.com/zulip/zulip.git
synced 2025-11-11 09:27:43 +00:00
ea6934c26d
Zulip has had a small use of WebSockets (specifically, for the code path of sending messages, via the webapp only) since ~2013. We originally added this use of WebSockets in the hope that the latency benefits of doing so would allow us to avoid implementing a markdown local echo; they were not. Further, HTTP/2 may have eliminated the latency difference we hoped to exploit by using WebSockets in any case. While we’d originally imagined using WebSockets for other endpoints, there was never a good justification for moving more components to the WebSockets system. This WebSockets code path had a lot of downsides/complexity, including: * The messy hack involving constructing an emulated request object to hook into doing Django requests. * The `message_senders` queue processor system, which increases RAM needs and must be provisioned independently from the rest of the server). * A duplicate check_send_receive_time Nagios test specific to WebSockets. * The requirement for users to have their firewalls/NATs allow WebSocket connections, and a setting to disable them for networks where WebSockets don’t work. * Dependencies on the SockJS family of libraries, which has at times been poorly maintained, and periodically throws random JavaScript exceptions in our production environments without a deep enough traceback to effectively investigate. * A total of about 1600 lines of our code related to the feature. * Increased load on the Tornado system, especially around a Zulip server restart, and especially for large installations like zulipchat.com, resulting in extra delay before messages can be sent again. As detailed in https://github.com/zulip/zulip/pull/12862#issuecomment-536152397, it appears that removing WebSockets moderately increases the time it takes for the `send_message` API query to return from the server, but does not significantly change the time between when a message is sent and when it is received by clients. We don’t understand the reason for that change (suggesting the possibility of a measurement error), and even if it is a real change, we consider that potential small latency regression to be acceptable. If we later want WebSockets, we’ll likely want to just use Django Channels. Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
30 lines
1.2 KiB
Python
30 lines
1.2 KiB
Python
import os
|
|
|
|
ZULIP_VERSION = "2.2.dev+git"
|
|
# Add information on number of commits and commit hash to version, if available
|
|
zulip_git_version_file = os.path.join(os.path.dirname(os.path.abspath(__file__)), 'zulip-git-version')
|
|
if os.path.exists(zulip_git_version_file):
|
|
with open(zulip_git_version_file) as f:
|
|
version = f.read().strip()
|
|
if version:
|
|
ZULIP_VERSION = version
|
|
|
|
LATEST_MAJOR_VERSION = "2.1"
|
|
LATEST_RELEASE_VERSION = "2.1.1"
|
|
LATEST_RELEASE_ANNOUNCEMENT = "https://blog.zulip.org/2019/12/13/zulip-2-1-released/"
|
|
|
|
# Bump the minor PROVISION_VERSION to indicate that folks should provision
|
|
# only when going from an old version of the code to a newer version. Bump
|
|
# the major version to indicate that folks should provision in both
|
|
# directions.
|
|
|
|
# Typically,
|
|
# * adding a dependency only requires a minor version bump;
|
|
# * removing a dependency requires a major version bump;
|
|
# * upgrading a dependency requires a major version bump, unless the
|
|
# upgraded dependency is backwards compatible with all of our
|
|
# historical commits sharing the same major version, in which case a
|
|
# minor version bump suffices.
|
|
|
|
PROVISION_VERSION = '67.0'
|