# Kong 1.2.0rc2 available for testing!

**URL:** <https://discuss.konghq.com/t/kong-1-2-0rc2-available-for-testing/3663>\
**Category:** General\
**Created:** [May 31, 2019, 5:33pm UTC](https://discuss.konghq.com/t/kong-1-2-0rc2-available-for-testing/3663 "2019-05-31T17:33:17Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![bungle](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/bungle/32/13_2.png) [@bungle](https://discuss.konghq.com/u/bungle)\
**Post date:** [May 31, 2019, 5:33pm UTC](https://discuss.konghq.com/t/kong-1-2-0rc2-available-for-testing/3663/1 "2019-05-31T17:33:17Z")

</div>

# Time for a new release candidate Kong folks!

This is the second release candidate for our next release, **Kong 1.2.0rc2**!

The release brings **improvements to reduce P95 latency** and **consolidates declarative configuration support**. It also comes with **newly open sourced plugins** , previously only available to Enterprise customers, and a few features around usability.

### Download

📦[Download Kong 1.2.0rc2](https://bintray.com/kong) today — as always we are looking forward for your feedback!

- ⚠ All Bintray repositories have been renamed from `kong-community-edition-*` to `kong-*` .
- ⚠ All Kong packages have been renamed from `kong-community-edition` to `kong` .

For more details about the updated installation, please visit the official docs: [https://konghq.com/install](https://konghq.com/install/).

### What’s New since Kong 1.2.0rc1

- 🚀 Core
  - Schema fields can now be marked immutable
  - DAO operations can now be passed a new options `no_broadcast_crud_event` to prevent Kong firing the worker events.
  - Fix to an issue introduced in `1.2.0rc1` where `init_worker` was not being called on plugins that implemented it

- 🔌 Plugins
  - The `request-transformer` and `request-transformer-advanced` (previously only available in Enterprise) plugins were merged
  - Fix to an issue where `:new` was not always called when Plugins deep-inherited from BasePlugin

- 💲 CLI
  - Fix `db_import` to upsert via deterministic v5 UUIDs

### And a recap of all the new stuff in the 1.2.0 release candidate series 🎆

- 🚀 Core
  - **Asynchronous router updates** : introduce a configuration properties `router_consistency` , with two possible values: `strict` and `eventual` . If set to `eventual`, whenever your Kong configuration changes, router update operations are performed out of the proxy path, asynchronously, reducing P95 latency when performing runtime Services/Routes manipulation.
  - **Cache warmup** of Kong entities at initialization. A new configuration directive `db_cache_warmup_entities` was introduced, allowing users to specify which entities should be preloaded. Cache warmup allows for ahead of time DNS resolution for Services with a hostname. This feature reduces first requests latency, improving P99 latency.
  - **Wildcard SNI matching** : the `ssl_certificate_by_lua` phase (and stream preread) is now able to match an SNI against any registered wildcard SNI.
  - **HTTPS routes can now be matched by SNI** : the `snis` route attribute can now be set for HTTPS routes and is used as a routing attribute
  - New optional configuration properties for PostgreSQL concurrency control: `pg_max_concurrent_queries` sets the maximum number of concurrent queries to the database; `pg_semaphore_timeout` allows you to tune the timeout for acquiring access to the database connection. The default behavior remains the same, with no concurrency limitation.

- 📄 Declarative configuration
  - **Hash checking for declarative configuration** , avoiding reloading if the configuration has not changed. The `/config` endpoint now accepts a `check_hash` query argument; hash checking only happens if its value is set to `1`.
  - The loading of declarative configuration is now done atomically, and with a safety check to verify that the new configuration fits in memory.

- ⚙ Admin API
  - **Entity schema validation endpoints** : you can use the new endpoint `/schemas/:entity_name/validate` to validate an instance of any entity type in Kong without creating the entity
  - **Memory statistics** in the `/status` endpoint. The response now includes a `memory` field, which contains `lua_shared_dicts` and `workers_lua_vms` , with stats on shared dictionaries and workers Lua VM memory usage.

- 🔌 Plugins
  - **proxy-cache** : we open sourced the [HTTP proxy cache plugin](https://github.com/kong/kong-plugin-proxy-cache), previously an Enterprise-only feature
  - New data available for logging plugins: log request TLS version, cipher, and verification status.

- 👷‍♂️ PDK
  - New function `kong.node.get_memory_stats`
  - Inheriting from `BasePlugin` is now optional

Plus of course the usual amount of bugfixes and internal improvements!

### Upgrade Path ⬆

You can upgrade from 0.14.1 or any release in the 1.x series (Note: upgrading from a pre-0.14 cluster is **not** supported). You can use a Blue/Green deployment method to update: “Blue” means your current version (for example, 0.14.1, 1.0.x or 1.1.x), “Green” means the new version 1.2.0rc2:

1. Download 1.2.0rc2, and configure it to point to the same datastore as your Blue cluster (running 0.14, 1.0 or 1.1). Run `kong migrations up`.
2. Both Blue and Green nodes can now run simultaneously on the same datastore. Start provisioning 1.2.0rc1 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your Blue cluster instead.
3. Gradually divert traffic away from your Blue nodes, and into your 1.2.0rc2 cluster. Monitor your traffic to make sure everything is going smoothly.
4. When your traffic is fully migrated to the Green 1.2.0rc2 cluster, decommission your Blue nodes.
5. From your 1.2.0rc2 cluster, run: `kong migrations finish`. From this point on, it will not be possible to start Blue nodes pointing to the same datastore anymore. Only run this command when you are confident that your migration was successful. From now on, you can safely make Admin API requests to your 1.2.0rc2 nodes.

### Install 1.2.0rc2 on a fresh datastore ⬇

Since version 1.0, Kong uses a new, improved migrations framework. The following commands can be run to prepare a new 1.2 cluster from a fresh datastore:

```auto
$ kong migrations bootstrap [-c kong.conf]
$ kong start [-c kong.conf]

```

### What’s next 🚀

Depeding on the community feedback, we are going to either tag and release 1.2.0 final or make a new release candidate 1.2.0rc3.

As always, consider yourself encouraged to reach out to us here or via [GitHub issues](https://github.com/Kong/kong/issues) if you have any questions or feedback about this release! Your feedback is essential to make Kong better!