# deprecated The state of an API, technology, feature, functionality, or service that is no longer recommended or in active development and may be removed or retained for compatibility. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Deprecating OpenCensus compatibility requirements DevFeed: [Deprecating OpenCensus compatibility requirements]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-06-19T22:53:47Z Content type: news Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [deprecated](), [migration](), [SDKs]() Tags: [deprecated](), [java](), [javascript](), [migrate](), [migration](), [opentelemetry](), [python](), [sdks]() ### AI overview The OpenTelemetry Specification project deprecated OpenCensus compatibility requirements on June 12, 2026. New SDKs and implementations no longer need to add OpenCensus compatibility, while existing shims may continue receiving maintenance during the deprecation period. New work should use native OpenTelemetry APIs, SDKs, and OTLP-based workflows. ### Source excerpt On June 12, 2026, the OpenTelemetry Specification project merged PR #5138, deprecating OpenCensus compatibility requirements in the specification. This change updates the specification to match where the ecosystem already is: OpenCensus has been archived since July 31, 2023, and the OpenTelemetry shims for OpenCensus have provided a stable migration bridge for more than three years. This is a deprecation of specification requirements, not an immediate removal of compatibility material and not a requirement to remove existing shim artifacts right away. ## NixOS 26.05 released DevFeed: [NixOS 26.05 released]() Original publisher: [Read original article]() Author: NixOS Published: 2026-05-30T07:00:00Z Content type: release Language: en Sources: [NixOS Announcements]() Topics: [Nix](), [Linux](), [releases](), [Release notes](), [systemd](), [configuration](), [modules](), [deprecated](), [Package manager]() Tags: [2026](), [accessibility](), [configuration](), [deprecated](), [end-of-life](), [gcc](), [linux](), [llvm](), [macos](), [modules](), [nix](), [nixos](), [release](), [release-notes](), [systemd](), [x86-64]() ### AI overview NixOS 26.05, named "Yarara," is publicly available as a new Linux distribution release. The announcement covers package, module, configuration, systemd initrd, platform-support, GNOME, and compiler changes, along with support timelines for NixOS 26.05 and the previous 25.11 release. ### Source excerpt Hey everyone, we are yayayayaka and jopejoe1, the release managers of the newest release of NixOS. We are very proud to announce the public availability of NixOS 26.05 "Yarara". NixOS is a Linux distribution. Its underlying package repository Nixpkgs can also be used on other Linux systems and macOS with the Nix package manager. This release will receive bugfixes and security updates for seven months (up until 2026-12-31). The old release 25.11 "Xantusia" is now officially deprecated and will reach its end-of-life and stop receiving security updates after 2026-06-30. NixOS Release Notes Highlights New Modules Backward Incompatibilities Other Notable Changes Nixpkgs Release Notes Highlights Backward Incompatibilities Other Notable Changes Nixpkgs Library Upgrade Instructions ISO Image Downloads The 26.05 release was made possible due to the efforts of 2842 contributors, who authored 59703 commits since the previous release. Highlights Our vast and routinely maintained set of packages has also been updated. This release of Nixpkgs Added 20442 new packages Updated 20641 existing packages Removed 17532 outdated packages, in an effort to keep the package set maintainable and secure. In addition to packages from Nixpkgs, the NixOS Linux distribution also features composable configuration modules and integration tests for distributed systems. This release of NixOS Added 85 new modules and 1547 configuration options Removed 25 outdated modules and 355 configuration options. systemd stage 1 Stage 1 (a.k.a. initrd) is now based on systemd by default, and the old scripted implementation is deprecated and scheduled for removal in 26.11. Deprecation of x86_64-darwin This will be the last release of Nixpkgs to support x86_64-darwin. Platform support will be maintained and binaries built until Nixpkgs 26.05 goes out of support at the end of 2026. For 26.11, due to Apple's deprecation of the platform and limited build infrastructure and developer time, we will no longer build packa ## IPLD 2025 Review: From Monoliths to Modules DevFeed: [IPLD 2025 Review: From Monoliths to Modules]() Original publisher: [Read original article]() Author: Volker Mische Published: 2026-01-19T00:00:00Z Content type: article Language: en Sources: [IPFS]() Topics: [Rust](), [modules](), [migration](), [IPFS](), [AT Protocol](), [deprecated]() Tags: [deprecated](), [ipfs](), [migration](), [modules](), [object-object](), [protocol](), [rust]() ### AI overview The article reviews progress in the IPLD ecosystem during 2025 and previews work for 2026. It describes the Rust IPLD implementation's migration to separate crates, its deprecation, improved performance for Python DAG-CBOR and Bluesky custom feeds, and a migration path to Serde-based crates. ### Source excerpt The year that brought us modular Rust libraries, faster DAG-CBOR, stable multiformats, and a simpler on-ramp with DASL. ## Deprecations, Defaults, and Details: The Subtle Tweaks You Might Miss in OpenAPI 3.2 DevFeed: [Deprecations, Defaults, and Details: The Subtle Tweaks You Might Miss in OpenAPI 3.2]() Original publisher: [Read original article]() Author: Zaid Daba'een Published: 2025-10-28T10:04:36Z Content type: article Language: en Sources: [DeveloperHub.io]() Topics: [OpenAPI Specification](), [deprecated](), [Documentation](), [Structured-data]() Tags: [deprecated](), [documentation](), [engineering](), [examples](), [features](), [openapi](), [schema](), [schemas]() ### AI overview This article explains less prominent refinements in OpenAPI 3.2, including broader deprecation support, clarified defaults, improved examples, and changes to schema references. These updates aim to make API specifications and generated documentation more consistent and predictable. ### Source excerpt OpenAPI 3.2 brings subtle refinements that make specs cleaner and more predictable, from improved deprecation handling to clarified defaults, schema rules, and examples. ## Announcing Lix 2.93 "Bici Bici" DevFeed: [Announcing Lix 2.93 "Bici Bici"]() Original publisher: [Read original article]() Published: 2025-05-06T00:00:00Z Content type: release Language: en Sources: [News on Lix]() Topics: [releases](), [Release notes](), [Nix](), [upgrade](), [deprecated](), [configuration]() Tags: [announce](), [asynchronous](), [bugfixes](), [configuration](), [deprecated](), [release](), [upgrade](), [version]() ### AI overview The Lix team announces version 2.93, a major release focused on bug fixes and continued integration with the KJ asynchronous runtime. The release also deprecates CR/CRLF line endings and literal NUL bytes in Nix expressions, which produce errors by default. ### Source excerpt We at the Lix team are proud to announce our fourth major release, version 2.93 "Bici Bici". This release focuses on bugfixes and continues integrating Lix with the KJ asynchronous runtime, in order to replace the previous bespoke implementation. ## Announcing Lix 2.92 "Bombe glacée" DevFeed: [Announcing Lix 2.92 "Bombe glacée"]() Original publisher: [Read original article]() Published: 2025-01-18T00:00:00Z Content type: release Language: en Sources: [News on Lix]() Topics: [Nix](), [Protocol (disambiguation)](), [async](), [C++](), [deprecated](), [configuration]() Tags: [announce](), [async](), [c-plus-plus](), [configuration](), [deprecated](), [improvements](), [protocol](), [release](), [version]() ### AI overview Lix 2.92 is a major release focused on evolving its evaluator and store, improving evaluator speed, and removing rarely used and troublesome Nix language features. It also reworks the daemon with asynchronous C++ code and begins deprecating problematic language features. ### Source excerpt We at the Lix team are proud to announce our third major release, version 2.92 "Bombe glacée". This release focuses on evolution work of the evaluator and store in order to be able to replace the Nix store protocol, to make the evaluator faster, and to remove rarely-used and troublesome features of the Nix language. ## Backwards compatibility in Keycloak releases DevFeed: [Backwards compatibility in Keycloak releases]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2024-10-08T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [version](), [client library](), [API](), [deprecated]() Tags: [api](), [client-library](), [compatibility](), [deprecated](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [releases](), [saml](), [sso](), [version]() ### AI overview Keycloak announces changes to its release model after version 26.0. The server will receive four minor releases each year and a major release every two to three years, while client libraries will be released separately and support all currently supported server releases. ### Source excerpt With four major releases of Keycloak every year it can be a daunting task to keep deployments up to date. Especially, since the number of breaking changes have drastically increased the last couple years. Combine this with the importance of patching deployments quickly for vulnerabilities, this can leave many deployments open to known vulnerabilities as the time and effort required to update to the latest release is too costly. Additionally, currently Keycloak client libraries are released together with the server, resulting in new major versions of a client library, where in fact there can be no changes at all, or perhaps only a bug fix or two. For these reasons, after Keycloak 26.0 is released there will be some changes to how Keycloak is being released: Keycloak server will have 4 minor releases every year, and a major release every 2-3 years Keycloak client libraries will be released separately. The latest client library release will support all currently supported Keycloak server releases We will continue to bring new features and enhancements to Keycloak in each release, and we are committed to doing so in a backwards compatible way, making it seamless and easy to upgrade. When a minor comes with breaking changes, such changes will be opt-in. This will be driven through versioning where the currently default version for a Feature or an API can not change in a minor release, and there will be a new version that can be explicitly enabled. The current version of a Feature or API can be deprecated in a minor, but will not be removed until the next major version. This will allow you to gradually roll-out new Feature or API versions separately from upgrading. You can choose to get ready for the next major release early, or wait and do it in one go. Backwards compatibility guarantees will only be given to Features and APIs that are fully supported. Preview features or preview APIs, as well as non-public APIs may change at any time. ## How old are Official Docker images? 2024 Edition DevFeed: [How old are Official Docker images? 2024 Edition]() Original publisher: [Read original article]() Author: Tom Published: 2024-03-24T00:00:00Z Content type: article Language: en Sources: [Tomasz Gągor]() Topics: [Docker](), [docker images](), [Docker Hub](), [centos](), [Debian](), [Ubuntu](), [openjdk](), [Bash](), [Script](), [deprecated]() Tags: [bash](), [centos](), [centos-docker-image](), [debian](), [debian-docker-image](), [deprecated](), [docker](), [docker-hub](), [docker-image-age](), [docker-image-updates](), [docker-images](), [dockerfiles](), [eclipse](), [end-of-life](), [images](), [official-docker-images](), [openjdk](), [script](), [ubuntu](), [ubuntu-docker-image]() ### AI overview An analysis of the age and update status of official Docker images in 2024. It reports that modern OS images are generally reasonably current, while CentOS and OpenJDK images have reached important lifecycle or maintenance milestones. ### Source excerpt Discover the current age and update status of various official Docker images, including CentOS, Ubuntu, and Debian, in the 2024 edition of this analysis. ## Vulnerability in long deprecated OpenID authentication method in Flask AppBuilder DevFeed: [Vulnerability in long deprecated OpenID authentication method in Flask AppBuilder]() Original publisher: [Read original article]() Author: Apache Airflow Published: 2024-02-26T00:00:00Z Content type: article Language: en Sources: [Apache Airflow Blog]() Topics: [vulnerability](), [Authentication](), [airflow](), [Flask](), [openid](), [deprecated](), [OpenID connect (OIDC)]() Tags: [airflow](), [authentication](), [deprecated](), [flask](), [openid](), [upgrade](), [version](), [vulnerabilities](), [vulnerability]() ### AI overview This article describes a vulnerability in Flask AppBuilder's long-deprecated OpenID authentication method. Users with AUTH_OID configured could be exposed to identity takeover through a forged request and an attacker-controlled OpenID service. The article recommends switching authentication methods or upgrading to Apache Airflow 2.8.2, which uses Flask AppBuilder 4.3.11. ### Source excerpt Vulnerability in long deprecated OpenID authentication method in Flask AppBuilder Recently Islam Rzayev made us aware of a vulnerability in the long deprecated OpenID authentication method in Flask AppBuilder. This vulnerability allowed a malicious user to take over the identity of any Airflow UI user by forging a specially crafted request and implementing their own OpenID service. While this is an old, deprecated and almost not used authentication method, we still took the issue seriously. This issue ONLY affects users who have AUTH_OID set in their webserver_config.py file as AUTH_TYPE. This is a very old and deprecated authentication method that is unlikely to be used by anyone. We would like to advise even the small number of our users that still use this authentication method to take an immediate action and either upgrade to Apache Airflow 2.8.2 or switch to another authentication method (or apply a workaround we provide if they cannot do either of the above immediately). Important to stress, because many of the users might get confused by the name, OpenID is NOT the same as OpenID Connect. Those are completely different protocols and while OpenID Connect (also known as OIDC) is a modern, widely used protocol, OpenID is a legacy protocol that has been deprecated more than 10 years ago and since then has been abandoned by almost everyone in the community, including all services in Flask AppBuilder example services that supported it, so it is highly unlikely someone is still using it. Due to this highly unlikely configuration the Flask AppBuilder CVE is just "Moderate" not "Critical". It affects a very small (if any) number of users and it's not likely to be a target for an attack. However, we still advise our users who still use AUTH_OID to apply remediation. This vulnerability is fixed in Flask Appbuilder 4.3.11 and Apache Airflow 2.8.2 uses that version of Flask Application Builder. We advise users who still use this authentication method to either switch to a ## Swampy Refactor: Converting Otto Bus to Flows DevFeed: [Swampy Refactor: Converting Otto Bus to Flows]() Original publisher: [Read original article]() Published: 2023-07-17T17:18:36Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [migration](), [Coroutines](), [deprecated](), [Code](), [RxJava](), [Kotlin](), [Git]() Tags: [code](), [coroutines](), [deprecated](), [flow](), [git](), [migration](), [otto-bus](), [refactor](), [rxjava](), [swampy]() ### AI overview This tutorial explains how to migrate an Android application from the deprecated Otto Bus event bus to Kotlin Flow. It presents an incremental, event-by-event process and notes that the work may require architectural refactoring, dependency-injection changes, and testing. ### Source excerpt The story starts I was wandering around my day job's code base and I happened on a time capsule - a pristine Java Activity studded with semi-colons, a snapshot of how we built things in 2014. All the member variables started with m and there was plenty of logic to update the screen and dictate actions. Despite being old, it's still used every day by users. Why would I change it? The Bus disappears Well, it got its data from a subscription to the Otto Bus. Otto Bus was deprecated in 2016. A blog post suggested migrating to RxJava, but since our code base standard now involves coroutines, Flows, and in some cases, LiveData, I decided to remove deprecated libraries and complete the partial migrations we started some time ago. This blog post summarizes how to migrate from Otto Bus to Flow. I've also created a Git repo with a simplified example that uses Otto Bus, with a conversion to Flow in the commit history. Check out the otto-bus tag for the working Otto Bus version and the flow tag for the converted Flow version. I am sparing you the Java to Kotlin conversions. This toy app lets you tap on the 8 ball for a message. It uses Otto Bus to notify the 8 Ball that a new message is needed as well as when a new message is available. How to tackle the migration - step by step Here are the basic steps for this kind of migration: Pick one event Find All the producers of this event (hopefully, there is only one but don't count on it) Replace with compatible functionality. We'll look at how to choose compatible functionality in the next section. Things will be broken. Find all subscribers of this event by looking for @Subscribe annotations. Replace with a matching access mechanism. Things should work at this point. Test that everything that used this one event still works Repeat with the next event until there are no events left to migrate Remove the Otto bus and it's dependencies Celebrate! Of course this looks deceptively simple. As simple as it is to add otto bus to a code ba ## When Android Compat Libraries Do Not Prevent New API Compatibility Issues DevFeed: [When Android Compat Libraries Do Not Prevent New API Compatibility Issues]() Original publisher: [Read original article]() Author: Danny Preussler Published: 2021-01-04T19:34:03Z Content type: tutorial Language: en Sources: [Stories by Danny Preussler on Medium]() Topics: [Android](), [Jetpack](), [deprecated](), [Mobile]() Tags: [android](), [android-app-development](), [androiddev](), [compiler](), [deprecated](), [fragmentation](), [jetpack](), [kotlin](), [linter]() ### AI overview This tutorial explains why Android compatibility libraries do not all work the same way. Some duplicate platform APIs, while others bridge to the original APIs, so developers still need appropriate API-level checks and should avoid using the "NewApi" suppression indiscriminately. ### Source excerpt And why you should avoid using the "NewApi" suppression! https://unsplash.com/photos/EgGIPA68Nwo The idea of "Compat" libraries was probably one of the key aspects of Android dominating the mobile space. Other than with iOS, Android users often could not update their operating system after a new version launch, simply as their phones won't allow them to, the Android problem of fragmentation. But developers still wanted to use the latest features to compete. The solution was simple: instead of adding new APIs to the operating system, you shipped those directly with your app by using a "backport" version Google gave you. It all started with ActionBar Sherlock by Jake Wharton then got adopted by Google with in their "support libraries". Later on, this was mirrored as AndroidX under the Jetpack umbrella. Same but different Under the hood, not all of those "compat"-APIs are made the same way. Some, like the ones for Fragments, are complete copies of the code. You either use android.app.Fragment from the OS (actually deprecated) or androidx.fragment.app.Fragment. Both don't share any code or have a common base class (which is why we also have two versions of the FragmentManager). On the other handAppCompatActivity for example, simply extends the original Activity. AlsoAppCompatImageButton still is an ImageButton! We can see that sometimes these "Compat"-classes are just a "bridge" to add missing functionalities and sometimes they are complete duplicates. Let's look at another example! One area that changed a lot over time is the notification API from Android. There was a time where every Google I/O introduced a new API change. Good that we have NotificationManagerCompat to save us!? If, for example, we need to get the notification channel groups: val groups = notificationManagerCompat.notificationChannelGroups We don't need to worry about the groups being supported on all OS versions, as it is handled under the hood for us: public List getNotific ## Turning Off Ruby Deprecation Warnings When Running Tests DevFeed: [Turning Off Ruby Deprecation Warnings When Running Tests]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2020-01-28T00:00:00Z Content type: tutorial Language: en Sources: [Scott Johnson]() Topics: [Rails](), [Ruby](), [test](), [deprecated]() Tags: [deprecated](), [rails](), [ruby](), [test](), [tests]() ### AI overview A Rails 6 and Ruby 2.7 project can silence deprecation warnings during tests by setting `$VERBOSE=nil` in `config/environments/test.rb`. The article also notes that `RUBYOPT="-W0"` works with `rake` but not with `rails` for running tests. ### Source excerpt The combination of Rails 6 and Ruby 2.7, or perhaps just Rails 6, introduced some new deprecation warnings and, lately, I've been seeing this cruft constantly: rails test test/models/ Running via Spring preloader in process 34024 /Users/sjohnson/.rvm/gems/ruby-2.7.0/gems/activemodel-6.0.2.1/lib/active_model/type/integer.rb:13: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call /Users/sjohnson/.rvm/gems/ruby-2.7.0/gems/activemodel-6.0.2.1/lib/active_model/type/value.rb:8: warning: The called method `initialize' is defined here /Users/sjohnson/.rvm/gems/ruby-2.7.0/gems/activerecord-6.0.2.1/lib/active_record/connection_adapters/postgresql/oid/specialized_string.rb:12: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call /Users/sjohnson/.rvm/gems/ruby-2.7.0/gems/activemodel-6.0.2.1/lib/active_model/type/value.rb:8: warning: The called method `initialize' is defined here And, in the immortal words of Twisted Sister, we're not going to take it anymore. The solution is a bit more byzantine than I have found in the Rails world and a bunch of the options in the Stack Overflow "top of Google" but no longer accurate post no longer work or aren't quite what you expect. The easy solution is to add: $VERBOSE=nil to the top of config/environments/test.rb so it looks like this: $VERBOSE=nil Rails.application.configure do # Settings specified here will take precedence over those in config/application.rb. # The test environment is used exclusively to run your application's # test suite. You never need to work with it otherwise. Remember that # your test database is "scratch space" for the test suite and is wiped # and recreated between test runs. Don't rely on the data there! config.cache_classes = false Obviously the rest of the file has to be there but that $VERBOSE=nil silences all the cruft. One other solution, RUBYOPT="-W0", prepended before you run the test doesn't work ## Keycloak Community Newsletter #2 DevFeed: [Keycloak Community Newsletter #2]() Original publisher: [Read original article]() Author: Sébastien Blanc Published: 2019-05-06T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Amazon API Gateway](), [gateway](), [Kubernetes](), [Python](), [deprecated](), [OAuth 2.0](), [openid](), [Cloud Native Ecosystem]() Tags: [api](), [api-gateway](), [community](), [deprecated](), [gateway](), [idm](), [kerberos](), [keycloak](), [kubernetes](), [ldap](), [news](), [oauth2](), [openid](), [openid-connect](), [python](), [saml](), [sso]() ### AI overview The second Keycloak community newsletter highlights integrations with API gateways, a Python adapter client, clustering configuration guidance, Helm Chart changes, login-theme customization, and Keycloak with MicroProfile. It also reports the Keycloak 6.0.1 release, a revised versioning discussion, and a proposal for CNCF acceptance. ### Source excerpt We have a lot of news to share in this second edition, so fasten your seatbelt and let's go! News from the community First of all, we would like to thank the whole community, which has contributed to this edition by sharing their links, tips, and so on. An increasing number of API Management/Gateway solutions can now be integrated with Keycloak. Recently, Ambassador, an Open Source Kubernetes-Native API Gateway built on the Envoy Proxy, has added support for Keycloak; it has also published a quickstart to show how Keycloak can be used to add Github as Identity provider. We have some good news for Python users. Akhil Lawrence has created a Python Keycloak Adapter Client. Be sure to check out the really nice documentation that comes with many usage examples. Like any other project, setting up clustering can be somehow complex. Liqiang has shared with us his setup and configuration tips. Thanks again for sharing your knowledge with the community! The existing Keycloak Helm Chart has now been deprecated and is now replaced by the one managed by CodeCentric. Dmitry Telegin has created a really nice example on how you can dynamically brand your login theme for Keycloak. Check out the repository here. Hayri Cicek has written a nice introductory article on how to use Keycloak and MicroProfile. It even shows the usage of the brand new Client Scope "microprofile-jwt," which has been added in Keycloak 6.0.0. News from the project Keycloak 6.0.1 has been released. We know that some people were a bit confused by our new versioning schema. We hope that this blog post will clear it up. We started the proposal process for Keycloak to be accepted into the Cloud Native Computing Foundation (CNCF). We hope that this effort will significantly boost our community adoption with our ultimate goal of becoming the de facto solution for OAuth2/OpenID Connect within Open Source and Cloud Native. You can watch the presentation to the CNCF TOC (Technical Oversight Committee) here and the slides ## Keycloak Releases and Versioning DevFeed: [Keycloak Releases and Versioning]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2019-04-24T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [releases](), [Continuous Delivery (CD)](), [version](), [deprecated](), [migration](), [API](), [Keycloak](), [Vulnerabilities]() Tags: [continuous-delivery](), [deprecated](), [idm](), [kerberos](), [keycloak](), [ldap](), [migration](), [migration-guide](), [openid-connect](), [preview](), [release](), [release-cadence](), [releases](), [saml](), [security-vulnerabilities](), [sso](), [versioning]() ### AI overview Keycloak describes changes to its release cadence and versioning to support continuous delivery. Feature releases will occur roughly four times a year and increment the major version, while individual features may be marked as preview. The project also plans more frequent micro releases focused on critical bugs and security vulnerabilities. ### Source excerpt We are aiming to achieve a continuous delivery model with Keycloak. By that we mean it should be seamless to upgrade between Keycloak releases and to keep up to date with the latest release. This requires no breaking changes, but rather deprecating old APIs allowing time to migrate to new APIs. Traditional semantic versioning does not fit very well with this model. By following the mantra of continuous delivery we would forever be stuck on a major version and only update the minor version, and you could argue whether or not it would be correct to update the major version when an API that has been deprecated for a long period of time is removed. With this in mind, we have made some slight changes to our release cadence and versioning schema. For now, we will have a new feature release roughly 4 times each year. Each release will bump the major version number. That doesn't mean there are breaking changes, but until we perfect our continuous delivery model there may be some, so always refer to the migration guide prior to upgrading! We have also decided to drop the Final suffix from releases. That is simply because it is not needed as we have not done any beta or release candidates for a long time. In the spirit of continuous delivery, we will have individual features marked as preview rather than whole releases. As a final note, with the reduced release cadence we are planning to do more micro releases. This will be focused on critical bugs and security vulnerabilities. However, we may accept contributions to less critical bugs given the fix is well tested and has low risk of regressions. ## Kotlin Android Extensions: View access, caching, and deprecation DevFeed: [Kotlin Android Extensions: View access, caching, and deprecation]() Original publisher: [Read original article]() Published: 2017-08-16T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [Kotlin](), [Android](), [deprecated](), [Code](), [Cache](), [XML]() Tags: [android](), [bytecode](), [cache](), [deprecated](), [kotlin](), [kotlin-android-extensions](), [xml]() ### AI overview This tutorial explains Kotlin Android Extensions for accessing Android views by ID without repeated findViewById calls. It describes generated code, a local view cache, module setup, XML view access, imports, and how to inspect the generated Kotlin bytecode. The article notes that Kotlin Android Extensions are deprecated and recommends View Binding. ### Source excerpt Everything Android, Kotlin and other random topics ## How the keypress Event Differs Between Chrome, Safari, IE10, and Firefox DevFeed: [How the keypress Event Differs Between Chrome, Safari, IE10, and Firefox]() Original publisher: [Read original article]() Author: Monica Dinculescu Published: 2015-06-02T00:00:00Z Content type: article Language: en Sources: [Monica Dinculescu]() Topics: [keyboard](), [browsers](), [Chrome](), [Firefox](), [deprecated]() Tags: [browsers](), [chrome](), [code](), [deprecated](), [firefox](), [keyboard]() ### AI overview This article examines inconsistent keypress event behavior across browsers. Chrome, Safari, and IE10 emit keypress for printable characters, while Firefox 38 emits it for all typed input. It also discusses differences and deprecation involving keyCode, charCode, and key. ### Source excerpt The keypress event works maddeningly differently in Chrome/Safari and Firefox, and this is the story of how I spent two hours discovering that, so that hopefully you don't have to. Keypress what? A keypress event is one of the events you get when you mash on the keyboard. It's special because according to the spec, you should only get a keypress event for keystrokes that produce printable characters. So you'll get it for things like letters and symbols, but not for backspace and left arrow. It's a great event to have if you want to write some as-you-type validation on an input, and you want to be able to dismiss the non-printable characters (which will still generate key events, but are uninteresting to the validation bit). Chrome, Safari and IE10 agree with this interpretation, which is great news. To be contrarian, Firefox (38; I don't know about Aurora) always sends a keypress event for anything you type. It's basically a keydown event from what I see. Now you have to get rid of control characters yourself and you get write code that doesn't make sense on the other platforms! Yay! (not yay) I call shenanigans. Mind your keyCodes and charCodes From looking at the spec, we expect a keypress event to have: keyCode, a number code that represents the key you've pressed. For example, q is 113. This is allegedly deprecated, but don't worry, both Firefox and Chrome implement it, but differently. charCode, the unicode number of the key. This code only exists for keypress. Like before, it's deprecated, but like before, it's implemented by both browsers. Differently. key, the value of the key represented by the event. According to that spec, this one is unimplemented. Worry not, Firefox implements it just fine (Chrome doesn't). It is the hero we deserve, but not the one we get right now. 😭 What you get out of this is spectacularly annoying. I wrote some code that basically prints out what the keypress event looks like, and found: As promised, in Chrome/Safari/IE10, we only ## Don't use junit.framework DevFeed: [Don't use junit.framework]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2014-12-14T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Maven](), [deprecated](), [Code]() Tags: [classes](), [configuration](), [deprecated](), [import](), [junit](), [maven](), [maven-plugin](), [org](), [script]() ### AI overview The article recommends replacing deprecated junit.framework imports with org.junit imports and preventing old imports from entering new code. It suggests using a Bash script for replacement and restrict-maven-plugin configuration to fail builds that contain the old imports. ### Source excerpt Every once in a while I see somewhere a wrong import to the old, deprecated junit.framework instead of org.junit. ## Microsoft's changing platform support and the challenges for managed developers DevFeed: [Microsoft's changing platform support and the challenges for managed developers]() Original publisher: [Read original article]() Published: 2013-05-12T00:00:00Z Content type: opinion Language: en Sources: [Front Page on ReactOS Website]() Topics: [Microsoft](), [deprecated](), [Maintainability](), [Visual Basic]() Tags: [deprecated](), [developers](), [free](), [maintainability](), [microsoft](), [open-source](), [os](), [react](), [reactos](), [win32](), [winapi]() ### AI overview The article discusses how Microsoft's platform changes and deprecations affected managed developers. It considers the continued operation of Silverlight applications, the persistence of Visual Basic 6 and MFC applications, and the long-term maintainability problems created by outdated systems and limited tooling updates. ### Source excerpt In my last post, I talked a bit about how Microsoft's fixation on Metro/Modern and the appstore had resulted in it basically ignoring large swathes of its developer community. So that post got a lot more attention than I was expecting, with some agreeing and others disagreeing. Some discussions however took a turn where people began debating how much trouble, if any, developers were in with Microsoft's move. This was something that I had decided not to explore further because the previous post had already reached a fairly ridiculous length. ## A perspective: developers vs Microsoft DevFeed: [A perspective: developers vs Microsoft]() Original publisher: [Read original article]() Published: 2013-05-11T00:00:00Z Content type: opinion Language: en Sources: [Front Page on ReactOS Website]() Topics: [Microsoft](), [Windows](), [API](), [Development](), [win32](), [deprecated](), [C++]() Tags: [api](), [c-plus-plus](), [deprecated](), [developers](), [development](), [free](), [microsoft](), [open-source](), [os](), [react](), [reactos](), [win32](), [winapi](), [windows]() ### AI overview The article examines the tension between Windows developers and Microsoft. It explains that developers need APIs and platforms to evolve while preserving compatibility, but deprecated or unstable interfaces can require costly rewrites. It uses the aging, verbose, C-centric win32 API as an example of a platform that may eventually require a clean break because of technical debt and architectural limitations. ### Source excerpt Most people understand that Windows is used by a variety of people who have a variety of needs, ranging from corporate server to workstation to POS terminals to home PC and beyond. Most people accept that whenever Microsoft updates Windows, it has to balance the competing requirements to find some kind of workable compromise. There is however another set of competing requirements that many do not really register, even those that call themselves power users or are IT admins. ## Disruptor 2.10 Release DevFeed: [Disruptor 2.10 Release]() Original publisher: [Read original article]() Author: Michael Barker (noreply@blogger.com) Published: 2012-05-13T16:59:00Z Content type: release Language: en Sources: [Bad Concurrency]() Topics: [version](), [Maven](), [Maven Central](), [implementation](), [deprecated](), [generics](), [bug]() Tags: [bug](), [deprecated](), [generics](), [implementation](), [maven](), [maven-central](), [performance](), [release](), [version]() ### AI overview Disruptor 2.10 has been released. The release removes deprecated timeout methods, adds OSGI metadata and a Sequencer remainingCapacity() call, changes Sequence usage and implementation, fixes generics warnings, and reports an approximately 10% performance improvement related to an IBM JDK workaround. ### Source excerpt The Disruptor version 2.10 has been released. It is available from the Google Code download page and has been submitted to Maven central. Changes Remove deprecated timeout methods. Added OSGI metadata to jar file. Removed PaddedAtomicLong and use Sequence in all places. Fix various generics warnings. Change Sequence implementation to work around IBM JDK bug and improve performance by ~10%. Add a remainingCapacity() call to the Sequencer class. ## Satirical announcement about modifying access modifiers in open-source Java projects DevFeed: [Satirical announcement about modifying access modifiers in open-source Java projects]() Original publisher: [Read original article]() Author: Steve Yegge (noreply@blogger.com) Published: 2010-07-28T20:40:00Z Content type: opinion Language: en Sources: [Steve Yegge]() Topics: [Java](), [Open Source](), [Code](), [Java Language](), [class](), [constructor](), [deprecated](), [Perl]() Tags: [class](), [code](), [constructor](), [deprecated](), [java](), [open-source](), [perl](), [projects](), [source]() ### AI overview This satirical article describes a purported Wikileaks announcement to re-release open-source Java projects after changing access modifiers, removing most final and deprecated declarations, adding public constructors, and exposing fields. ### Source excerpt EYJAFJÖLL, ICELAND -- Java programmers around the globe are in a panic today over a Wikileaks press release issued at 8:15am GMT. Wikileaks announced that they will re-release the source code for thousands of Open Source Java projects, making all access modifiers 'public' and all classes and members non-'final'. Agile Java Developer Johnnie Garza of Irvine, CA condemns the move. "They have no right to do this. Open Source does not mean the source is somehow 'open'. That's my code, not theirs. If I make something private, it means that no matter how desperately you need to call it, I should be able to prevent you from doing so, even long after I've gone to the grave." According to the Wikileaks press release, millions of Java source files have been run through a Perl script that removes all 'final' keywords except those required for hacking around the 15-year-old Java language's "fucking embarrassing lack of closures." Moreover, the Perl script gives every Java class at least one public constructor, and turns all fields without getters/setters into public fields. "The script yanks out all that @deprecated shit, too," claims the controversial announcement. Longtime Java programmer Ronnie Lloyd of Austin, TX is offended by the thought of people instantiating his private classes. "It's just common sense," said Lloyd, who is 37. "If I buy you a house and put the title in your name, but I mark some of the doors 'Employees Only', then you're not allowed to open those doors, even though it's your house. Because it's really my house, even though I gave it to you to live in." Pacing and frowning thoughtfully, Lloyd continued: "Even if I go away forever and you live there for 20 years and you know exactly what's behind the doors -- heck, even if it's a matter of life and death -- plain old common sense still dictates that you're never, ever allowed to open them for any reason." "It's for your own protection," Lloyd added. Wesley Doyle, a Java web developer in Toronto, Canada is m