RTX5 Releases and Feature Availability
Use published source records to review packages and change notes. Supported clients, signing identity and tested feature scope need separate evidence; future work belongs on the roadmap.
Published packages and release records
Use the release source to match a package to its version and publication date. A repository release does not by itself certify a supported OS, a signed installer or a tested feature.
Loading published release records…
Filter and Search Version History
Loading published records. Categories match keywords in source notes; they do not certify a feature or fix.
Review a Published Release
This record follows the selected release filters. Match its package, source notes and tested environment before an upgrade; a repository tag does not certify stable behavior or compatibility.
Release Record and Verification
No matching source notes are available. Request the shipped changes and known issues before upgrading.
No build-level benchmark is verified here. Request the workload, hardware, method and result before relying on a speed claim.
A source release should identify affected tasks, workarounds and upgrade blockers. Absence of a listed issue does not mean no issues exist.
Publisher identity and signature validation are not established by repository publication. Verify them for the exact asset.
Supported OS, browser and client/server combinations require a named compatibility record. Mobile and web availability are not inferred from this tag.
Published Release History
Loading release history.
Feature Evidence Before Rollout
These review areas are not a shipped-feature catalog. Match any capability you need to a named release and original test evidence. No build mapping is verified for the items below.
Area 1: Feature Review
Anchored VWAP Indicator
Confirm the indicator definition, data source, warm-up, supported client and original output fixtures before claiming an available VWAP workflow.
Advanced Options Matrix
An options workflow needs entitled instruments, calculation conventions, supported order types and tested broker/adapter scope. Availability is not verified here.
Cloud-Synced Workspaces
Workspace synchronization needs a supported client matrix, conflict handling and persistence/reconnect tests. Universal parity is not assumed.
Telegram Signal Bots
External alert delivery needs a documented connector, scoped credentials, consent, rate limits and delivery/failure tests before publication.
Area 2: Feature Review
Desktop Backtesting
Desktop backtesting is planned. Publish licensed fixtures, cost/fill assumptions, reproducibility records and the tested compiler/desktop version.
Multi-Monitor Workstation
Publish tested window, monitor and display configurations for the named desktop build; no supported monitor count is established here.
Custom Synthetic Instruments
A synthetic instrument needs an authorized feed definition, formula semantics, missing-data behavior and test fixtures; this is not confirmed product support.
Institutional Volume Book
Depth display requires entitled market data and a tested update model. A chart does not establish visibility into hidden liquidity.
Area 3: Feature Review
Smart Trailing Stops
Order controls require a supported broker contract and tests for trigger, rejection, partial fill and recovery behavior. Stops cannot guarantee profit.
Economic Calendar Overlay
Calendar overlays require a licensed source, time-zone handling and verified update behavior for the client build.
Dark Pool Liquidity Scanner
Any liquidity-scanner claim needs a defined data source, method and limitations; inferred activity must not be presented as verified hidden orders.
One-Click Partial Close
Partial-close actions require supported account/order modes, size validation and reconciliation tests before a release claim.
Performance Evidence Requirements
No comparative benchmark is verified here. Before publishing an improvement, record the baseline and target builds, hardware, workload, sample size, measurement method and limitations for the relevant area below.
Measure client submission, broker validation and venue response separately. Publish timestamps, percentile latency and workload; no percentage gain or sub-millisecond result is verified.
Record chart count, indicator load, display resolution, GPU and frame-time measurements for both compared builds.
Measure synchronization and reconnect outcomes only on a supported client pair. No mobile/desktop timing or parity is established here.
Record dataset size, strategy settings, compiler and desktop build, peak memory and repeatability. Backtesting remains planned.
Measure calculation load and interface responsiveness with original indicator fixtures and documented CPU allocation.
Publish entitled feed depth, update rate, hardware, dropped-update policy and measured rendering behavior before a throughput claim.
Measure data-source response, pagination correctness, cache state and client responsiveness against a defined baseline.
Define startup readiness and capture repeated runs on stated hardware. A faster startup must not bypass account reconciliation.
Known Issues and Fix Validation
No complete build-specific issue register is published here. The areas below describe checks to request, not reported vulnerabilities or confirmed fixes. Record affected builds, reproduction steps, impact, workarounds and retest results; an empty issue list is not evidence that all issues are resolved.
Security Update Evidence
Security claims require a named build and reviewed evidence. These are review requirements, not assertions that a vulnerability occurred, a patch shipped or a certification was achieved. Publish sanitized impact and mitigation details through the approved disclosure process.
Review session expiry, revocation, replay protection and permission-denial outcomes for the named build. No specific vulnerability or shipped fix is asserted.
Publish approved data-at-rest scope, key handling and verification results before claiming a particular encryption guarantee.
Document supported authentication, recovery and session controls. Device or location checks require actual implementation and testing evidence.
Review API scopes, origin policy, credential handling and rejected unauthorized requests with sanitized test results.
Define retention, export, deletion and secret-handling boundaries. No absolute memory-erasure or capital-protection claim is made.
Mobile Release Evidence Pending
iOS and Android release/store evidence is not yet verified. The checks below describe what an approved client record needs; they are not app-store changelogs or claims that a mobile feature has shipped.
RTX5 for iOS
A published iOS record needs the official store URL, version/build, publisher, supported OS/device matrix and reviewed date.
List only tested iOS tasks and supported account/order modes; desktop feature parity is not assumed.
Record authentication, session expiry, reconnect, permission-denial and known-issue outcomes for the supported iOS build.
Any battery, latency or chart-performance claim needs a named device, OS, workload and reproducible measurement.
RTX5 for Android
A published Android record needs the official store URL, version/build, publisher, supported OS/device matrix and reviewed date.
Phone and tablet support require separate tested layouts and task coverage; neither is inferred from a desktop release.
Verify notification routing, authentication and account scope for the supported Android client before advertising those actions.
Document offline data limits and reconnect reconciliation. No offline trading or synchronized state is assumed.
Connect Feedback to Release Evidence
A feedback item should link the original request, approved scope, owner and tested release. The examples below describe review questions; no community vote count or delivered feature is established here.
Partial Close Hotkeys
A partial-close request needs the intended account mode, permitted quantities, confirmation behavior and test outcome before release.
Dark Pool Order Highlighting
A depth-display request needs an entitled source and clear limits; do not describe inferred or unavailable hidden liquidity as observed data.
Anchored VWAP
An indicator request needs a precise calculation definition, licensed inputs and original fixtures before availability is claimed.
Cloud-Synced Workspaces
A workspace-sync request needs a supported client matrix, conflict rules and tested reconnect behavior; mobile delivery is not confirmed.
Help Shape the Next Release
Email support@orrnn.com to describe a feature request or reproducible issue, including the client/build and expected outcome. Do not include account credentials or private trading data.
How Roadmap Items Become Releases
Future capabilities and their planning status belong on the roadmap. These are publication gates for a released item, not additional product promises or target dates.
Defined Scope
State the feature boundary and dependencies on the roadmap, with a responsible owner. A proposed scope is not a delivered capability.
Named Build
Identify an actual product build and source publication record. Do not invent a version or launch date to fill an empty field.
Tested Compatibility
Record supported clients, server/adapter versions and the workflows actually tested, including rejected or unavailable operations.
Reviewed Evidence
Keep original fixtures, test outcomes, known limitations and a named reviewer/date. A package checksum alone is insufficient.
Published Release Record
Publish shipped changes, known issues, package identity and upgrade/recovery guidance, then update the shared feature status from that evidence.
Follow Published Release Records
Use source records and a scoped support enquiry to follow changes. A weekly email service, in-terminal notification flow and RSS feed are not yet verified.
Release Enquiries
Ask the RTX5 team which update channels are available for your deployment. This enquiry does not subscribe you to an unimplemented mailing list.
Upgrade Guidance
Review the upgrade and recovery checklist, then confirm the supported procedure for your exact client and broker environment.
Release JSON Feed
The website JSON endpoint exposes available source release records. It is a publication feed, not a product API contract or an uptime guarantee.
Review Published Package Records
Loading package records.
Version Support Policy: Maintenance windows, supported upgrade paths and end-of-life dates require an approved build-specific policy. No fixed support duration or signed-archive guarantee is established here.
| Version | Release Date | Source Channel | Platform Availability | Package or Record |
|---|
Review a build, upgrade and recover
Use the published source records above when selecting a package. The review checklists below do not establish supported behavior; confirm the exact build, tested scope and known issues with the responsible owner.
Swipe horizontally to view all columns.
| Record | Details to confirm |
|---|---|
| Product and build | Desktop, mobile, web, Manager/Admin or runtime; exact build and release date. |
| Tested scope | Operating system or browser versions, server compatibility and the workflow actually tested. |
| Shipped changes | Feature or fix, affected versions and a reproducible example or test reference. |
| Known issues | Affected task, impact, workaround and conditions that should block an upgrade. |
| Package identity | Source asset, checksum and verified signing publisher. |
| Support and recovery | Supported upgrade path, backup format, compatibility limits and rollback procedure. |
- 01
Review with the broker
Confirm that the target build works with the deployed server, adapters, account permissions and algorithms. Obtain build-specific known issues and support guidance.
- 02
Save a recoverable state
Back up supported settings, templates and algorithm configuration using the current build’s documented method. Record the installed version and keep the approved prior installer.
- 03
Test before rollout
Use an approved demo or staging account to check login, market data, order lifecycle, history and required automation. Compare outcomes with the pre-upgrade baseline.
- 04
Upgrade and verify
Install the approved package, confirm its build identifier and repeat the agreed checks. Reconcile server-held account and order state before restoring normal operations.
- 05
Roll back only with a supported path
Stop new activity and involve the broker if checks fail. Confirm backward compatibility before reinstalling an earlier client or restoring settings; a server/schema downgrade requires its own recovery plan.
- 06
Record the outcome
Keep the tested build, date, environment, checks and unresolved issues with the deployment record. Link any newly confirmed feature to its release entry.
Review a Build Before Upgrading
Match the source package to its supported environment, known issues and recovery procedure. Get broker approval before replacing a client used for trading.