HMS Product Road Map
===

Version | Status | Target Timeframe | Key Features
------- | -------- | ---------------- | ---------------------------
2020.x  | *Unfunded* | TBD | Implement `hms update` and `hms upgrade` options to initiate a site-wide global topology upgrade without the human admin needing much knowledge of the global topology.  An admin with super access that inherited Perforce application just yesterday should be able to confidently upgrade the whole thing tomorrow. This is to include all Helix Core server products (p4d/p4broker/p4p) in the entire global topology.
2020.1  | Released | Added prototype Data Leaking Protection (DLP). | Prototype solution for providing Helix services to users who must "stay in their lane," and not be aware of things going they're not involved with. Ability to list clients, for example, is limited to the users own clients, and users cannot be listed except by a super user.
2019.1  | Released | Early March, 2019 | Back to a standalone project, bringing hardening updates and fixes.
w/SDP | Released | From 2016-2019 | Primarily hardening and bug fixes.
2016.1  | Released     | September 2016 | SDP Version Management, Topology Definition, Failover Support for **p4d**, **p4broker**, Replication Normalization, Simplified Replica/Edge Server Setup, Helix Component Status Visualization

Feature Descriptions
---

* **SDP "Tight Ship" Version Management** - A necessary step on the path to successful automation across multiple machines is to solve basic version management challenges for the SDP itself.  Essentially, Helix Core itself is used to version the SDP on all HMS hosts. An HMS host is any Perforce server process executes, be it a proxy, broker, master/commit server, replica, edge, Swarm, P4Search, etc.  The familiar SDP `/p4/common` structure is managed on all hosts from a single server, the p4hms server.  That server in turn uses Helix DVCS features to vastly simplify the process of updating the SDP from The Workshop, taking advantage of merging power to merge updates to the stock/public SDP into the local environment, which will have local configuration and optional customizations versioned locally.

* **Topology Definition** - HMS provides a data format to describe various aspects of Helix server components in use.

* **Failover Support for ...** - HMS will provide Scheduled and Unscheduled Failover for the specified components.

* **Replication Normalization** - HMS will not support all possible replication options.  Part of its value is that it will only the most useful replica types and usage options, based on Consulting experience working with customers, distilling the myriad potential options (all of which are useful in some context).  The normalization includes defining naming conventions for naming server specs that readily convey their usage.

* **Simplified Replica/Edge Server Setup** - All the complexities of creating and seeding a replica are distilled down to a command something like this example, to create a forwarding replica:
  `mkrep.sh -t fr -s bos -r bos-helix-02`