zulip/version.py

49 lines
1.9 KiB
Python
Raw Normal View History

import os
2021-05-04 02:36:29 +02:00
ZULIP_VERSION = "4.0-rc1+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
2020-07-16 11:13:43 +02:00
LATEST_MAJOR_VERSION = "3.0"
LATEST_RELEASE_VERSION = "3.0"
LATEST_RELEASE_ANNOUNCEMENT = "https://blog.zulip.org/2020/07/16/zulip-3-0-released/"
# Versions of the desktop app below DESKTOP_MINIMUM_VERSION will be
# prevented from connecting to the Zulip server. Versions above
# DESKTOP_MINIMUM_VERSION but below DESKTOP_WARNING_VERSION will have
# a banner at the top of the page asking the user to upgrade.
DESKTOP_MINIMUM_VERSION = "5.0.0"
DESKTOP_WARNING_VERSION = "5.2.0"
# Bump the API_FEATURE_LEVEL whenever an API change is made
# that clients might want to condition on. If we forget at
# the time we make the change, then bump it later as soon
# as we notice; clients using API_FEATURE_LEVEL will just not
# use the new feature/API until the bump.
#
# Changes should be accompanied by documentation explaining what the
# new level means in templates/zerver/api/changelog.md.
API_FEATURE_LEVEL = 62
# 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.
django: Upgrade Zulip to Django 3.2 LTS. This is a straightforward upgrade in terms of changes needed. Necessary changes were: - Set `DEFAULT_AUTO_FIELD` https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-auto-created-primary-keys - `The default_app_config application configuration variable is deprecated, due to the now automatic AppConfig discovery.` https://docs.djangoproject.com/en/3.2/releases/3.2/#automatic-appconfig-discovery To handle this one, we can remove default_app_config from zerver/__init__.py because it satisfies what release notes describe in https://docs.djangoproject.com/en/3.2/releases/3.2/#automatic-appconfig-discovery: "Most pluggable applications define an AppConfig subclass in an apps.py submodule. Many define a default_app_config variable pointing to this class in their __init__.py. When the apps.py submodule exists and defines a single AppConfig subclass, Django now uses that configuration automatically, so you can remove default_app_config." An important note is that rebuild-test-database needs to be run after this upgrade in dev environment - if tests are run with test db that was built on the previous version, they will fail due to a mysterious bug (?), where changing attributes of a user and .save()ing after logging in in the test via self.login_user, causes getting logged out - the next requests via self.client_get etc. are unauthed for some reason, unless self.login_user is called again. This behavior is no longer exhibited upon rebuilding the test db - and I can't reproduce it in production or dev db. So this can likely be reasonably dismissed as some quirk of the test client system that won't be relevant in the future and doesn't impact production.
2021-05-01 15:34:59 +02:00
PROVISION_VERSION = "142.0"