Related Pages

Related topics: Data Stores, Materialization, and Feature Retrieval, Feature Servers, Compute Engines, and Transformation Pipeline, Deployment, Kubernetes Operator, Web UI, and Operations

Feast Overview, Architecture, and Core Concepts

1. Purpose and Scope

Feast (Feature Store) is an open source feature store for machine learning. According to the project README, Feast is positioned as "the fastest path to manage existing infrastructure to productionize analytic data for model training and online inference" (README.md). It is designed to serve ML platform teams who must:

• Make features consistently available for training and serving by managing an *offline store* (historical, scale-out), a low-latency *online store* (real-time prediction), and a battle-tested *feature server* (README.md).
• Avoid data leakage by generating point-in-time correct feature sets so future feature values never leak into training data (README.md).
• Decouple ML from data infrastructure by exposing a single data access layer that abstracts feature storage from feature retrieval (README.md).

The minimal Feast deployment diagram lives at docs/assets/feast_marchitecture.png (README.md). Feast is a community project still under active development, with releases published regularly (v0.55.0 through v0.64.0 are tracked in the release history).

2. High-Level Architecture

Feast is organized as a multi-language ecosystem built around a declarative feature repository. The Python SDK is the primary user-facing surface; Java provides the high-throughput serving layer; the Go-based Kubernetes operator manages deployments.

flowchart LR
    A[Feature Repository<br/>feature_store.yaml + Python definitions] --> B[Feast CLI / SDK<br/>feast apply, materialize]
    B --> C[Registry<br/>file or SQL]
    B --> D[Offline Store<br/>BigQuery, Snowflake, Redshift, Parquet, File]
    B --> E[Online Store<br/>Redis, SQLite, DynamoDB, etc.]
    D -->|materialize| E
    E --> F[Feature Server<br/>Python feature_server.py or Java serving]
    F --> G[Online Inference<br/>get_online_features]
    F --> H[Transformation Service<br/>on-demand features]
    K[Feast Operator<br/>FeatureStore CR] --> F
    L[Feast Web UI] --> C

Key runtime pieces:

• Feature Repository — A version-controlled directory containing feature_store.yaml plus Python files that declare entities, feature views, and feature services (sdk/python/feast/templates/local/README.md).
• Registry — A file or SQL-backed catalog that records all defined objects. Templates document configuring a remote registry like s3://my-bucket/feast/registry.pb for production (sdk/python/feast/templates/gcp/README.md).
• Feature Server — Exposes HTTP/gRPC endpoints for online retrieval. The Java implementation lives in java/serving/ and is shipped as an executable jar (java/serving/README.md). The Python equivalent is started via feast serve --host 0.0.0.0 --port 6566 (sdk/python/feast/templates/pytorch_nlp/README.md).
• Transformation Service — A separate Helm sub-chart that computes on-demand features at request time (infra/charts/feast/charts/transformation-service/README.md).
• Feast Operator — A Kubernetes operator that deploys/manages Feast via the FeatureStore Custom Resource (infra/feast-operator/README.md).
• Feast Web UI — An experimental React UI launched via feast ui or imported as a module (ui/README.md).

3. Core Concepts

3.1 Feature Repository and Templates

A feature repository is bootstrapped with feast init and a template. Templates shipped in sdk/python/feast/templates/ include local, gcp, aws, snowflake, milvus, and pytorch_nlp (sdk/python/feast/templates/local/README.md, sdk/python/feast/templates/pytorch_nlp/README.md). Each template scaffolds a feature_store.yaml, demo data under data/, and a test_workflow.py that exercises the main Feast commands (sdk/python/feast/templates/local/README.md). The default local template configures SQLite for the online store, a file registry at data/registry.db, and a file offline store (sdk/python/feast/templates/pytorch_nlp/README.md).

3.2 Entities, Feature Views, and Feature Services

Feature definitions live in Python files such as example_repo.py or feature_definitions.py (examples/rag/README.md). Declarative objects include:

• Entities — join keys (e.g., customer_id, driver_id) used to look up features.
• Feature Views — groups of features sourced from a single data source, including BatchFeatureView, StreamFeatureView, and on-demand variants. Production configurations in the GCP/AWS templates wire these to Redshift, BigQuery, or Snowflake (sdk/python/feast/templates/gcp/README.md).
• Feature Services — named bundles of features consumed by a specific model version. The PyTorch NLP template defines sentiment_analysis_v1, sentiment_analysis_v2, and sentiment_training_features (sdk/python/feast/templates/pytorch_nlp/README.md).

3.3 Data Sources and Stores

The README enumerates supported data sources: Snowflake, Redshift, BigQuery, Parquet file, Azure Synapse + Azure SQL (contrib), Hive (community), Postgres (contrib), Spark (contrib), and Couchbase (contrib) (README.md). Online stores include Redis (default for production) and SQLite (default for demos) (sdk/python/feast/templates/pytorch_nlp/README.md). The Milvus template demonstrates vector-database integration for RAG workloads (sdk/python/feast/templates/milvus/README.md).

3.4 Serving and Retrieval

Two retrieval paths are documented:

• Online retrieval — get_online_features queries the online store via the feature server (sdk/python/feast/templates/gcp/README.md).
• Offline retrieval — historical feature joins for training, produced from the offline store with point-in-time correctness (README.md).

A DocEmbedder helper class automates the document-to-embeddings pipeline (chunking, embedding, FeatureView creation, online write) for RAG ingestion (examples/rag-retriever/README.md). The Docling example extends this by transforming PDFs into Parquet chunks suitable for embedding (examples/rag-docling/README.md).

4. Deployment Components

5. Known Issues and Community Notes

Several community-reported issues and release notes are relevant when adopting Feast:

• UI regression between v0.63.0 and v0.64.0 — the Feast Web UI reportedly breaks in the demo after upgrading (issue #6539).
• Missing zoned datetime feature type — Feast does not yet natively store timezone information alongside timestamps; users currently split zone info into a separate feature (issue #6536).
• get_online_features drops join keys on remote stores — when calling the SDK against remote feature servers, only the first entity key of a multi-join-key entity row is honored (issue #6488).
• v0.64.0 fixes — added async_supported to RedisOnlineStore and supplied missing feast init templates for the operator CRD (v0.64.0 release notes).
• v0.55.0–v0.63.0 fixes — improvements to PostgreSQL subquery aliasing, Trino-to-Feast type mapping, unix_timestamp_val serialization, transformation persistence, and project-filtered apply_data_source/delete_data_source (release notes).

6. See Also

• Feast Documentation
• Quickstart
• Examples Index
• Feast Operator Guides
• Java Serving Developer Guide
• RAG Examples

Related Pages

Related topics: Feast Overview, Architecture, and Core Concepts, Feature Servers, Compute Engines, and Transformation Pipeline

Data Stores, Materialization, and Feature Retrieval

Purpose and Scope

Feast is an open source feature store that bridges offline historical data and low-latency online serving. The system is organized around three primary storage and access components: an offline store for scalable historical feature generation and point-in-time joins, an online store for real-time feature retrieval, and a materialization process that continuously moves feature values from the offline store into the online store. The repository exposes these as pluggable backends so teams can pick the infrastructure that matches their scale and latency requirements. Source: README.md.

This page documents the online and offline store abstractions, the materialization flow, and the feature retrieval API surface, including the join-key handling that is central to both online reads and on-demand feature views.

Online Stores

The OnlineStore protocol defines the contract every backend must implement. It is defined in sdk/python/feast/infra/online_stores/online_store.py and is the surface through which feature servers read pre-computed feature values. Backends included in the repository include:

Version notes from the community: v0.64.0 added an async_supported property to RedisOnlineStore to better signal whether the backend can be used in async serving paths (v0.64.0 release notes), and v0.59.0 introduced the hybrid online store as a new official backend (v0.59.0 release notes).

Join-Key Handling

The online read API accepts a list of entity keys, each potentially composed of multiple join keys, and must return a row per entity key. The Go feature server encodes the resolved join keys, their types, and the request shape in getFeatureServiceSchema for logging and observability. Source: go/internal/feast/server/logging/featureserviceschema.go:21-65.

A known issue tracked in the community is that get_online_features against remote stores has dropped all but the first join key when multiple entity rows are passed (issue #6488). This is a recurring pain point for users who model composite entities and rely on the remote online store adapter to forward the full request to a server-side feature server.

Offline Stores

The offline store abstraction lives in sdk/python/feast/infra/offline_stores/offline_store.py and powers historical retrieval for training, backfills, and point-in-time joins. Recent releases have incrementally improved type fidelity and remote retrieval semantics:

• v0.55.0 added unix_timestamp_val handling in _serialize_val so that timestamp columns round-trip cleanly through the offline store pipeline (v0.55.0 release notes).
• v0.56.0 introduced date-wise historical data retrieval for remote offline stores (v0.56.0 release notes).
• v0.57.0 and v0.60.0 improved Trino-to-Feast type mapping for real, varchar, timestamp, decimal, and date types (v0.57.0, v0.60.0).
• v0.59.0 added get_table_query_string_with_alias() for PostgreSQL subquery aliasing to keep generated SQL deterministic (v0.59.0 release notes).

There is also an open feature request to add a zoned datetime feature type so that timezone information survives materialization and retrieval (issue #6536). Until that lands, users typically store the timestamp and zone as two separate features.

Materialization and Feature Retrieval

Materialization is the bridge between the offline and online worlds. It reads feature values from the offline store for a time window and writes the latest value per entity into the online store. v0.58.0 added the ability to force fully qualified feature names for materialization operations, which removes ambiguity when multiple feature views share feature names (v0.58.0 release notes). v0.57.0 fixed the Materialize API for on-demand feature views so that transformations resolve correctly during the move from offline to online (v0.57.0 release notes).

The typical retrieval flow is:

flowchart LR
    A[Client] -->|entity_keys| B[Feast SDK / Feature Server]
    B -->|resolve join keys| C{Online Store}
    C -->|Redis| D[(Redis)]
    C -->|Remote| E[Remote Feast Server]
    C -->|Hybrid| F[Local Cache + Remote]
    C -->|Milvus| G[(Milvus Vector Index)]
    C -->|feature values| B
    B -->|rows per entity| A

The Go feature server in this repository logs the resolved schema for each retrieval request, including all join keys (deduplicated) and the inferred types, which makes debugging issues like the join-key dropping bug in issue #6488 much easier in production. Source: go/internal/feast/server/logging/featureserviceschema.go:21-65.

Common Failure Modes

• Composite join keys over remote online store: as in issue #6488, only the first join key may be forwarded by the remote adapter. Workaround is to use a single concatenated join key or to read directly from a colocated online store.
• Timezone loss on materialization: timestamps lose zone information because zoned datetimes are not yet a first-class feature type (issue #6536). Store zone-aware and timestamp columns separately until the feature lands.
• Type mapping drift on Trino and PostgreSQL backends: addressed incrementally in v0.55–v0.60. Pin to a known-good minor version if you depend on a specific mapping behavior.

See Also

• Project overview and architecture
• Python feature server
• Feast Operator for Kubernetes deployment
• RAG and vector retrieval example

Related Pages

Related topics: Feast Overview, Architecture, and Core Concepts, Data Stores, Materialization, and Feature Retrieval, Deployment, Kubernetes Operator, Web UI, and Operations

Feature Servers, Compute Engines, and Transformation Pipeline

Feast exposes feature data to models and applications through a family of servers that share a common registry, online store, and offline store backplane. These servers, along with the compute engines that prepare data and the transformation pipeline that defines on-demand feature logic, form the runtime surface of the project.

Overview of Feast Servers

Feast ships four primary Python servers and one Go-embedded online service. Together they cover online retrieval, offline retrieval, registry access, on-demand transformation, and Model Context Protocol (MCP) integration.

Python Feature Server

The Python feature server is the default online retrieval service. It exposes get_online_features and related REST endpoints backed by a configurable online store. The Helm chart installs it as a separate pod whose image and ConfigMap can be overridden through application-override.yaml and application-secret.yaml. Source: infra/charts/feast/charts/feature-server/README.md.

When run with the MCP extra, the feature server also registers FastAPI routes as MCP tools. The example examples/mcp_feature_store/README.md shows the required install command pip install feast[mcp] and the log line INFO:feast.feature_server:MCP support has been enabled for the Feast feature server that confirms the protocol layer is wired in. Source: examples/mcp_feature_store/README.md.

Offline Feature Server and Registry Server

The offline feature server (alpha) and registry server (alpha) expose historical retrieval and registry browsing over HTTP. These complement the Java feature server listed in the project roadmap and are useful for language-agnostic clients.

Transformation Server

The transformation server is a dedicated gRPC service that computes on-demand features. Its Helm chart is published with version 0.64.0 and uses the image quay.io/feastdev/feature-transformation-server. Source: infra/charts/feast/charts/transformation-service/README.md. It is invoked when feature views define UDFs that must run at request time rather than at materialization time.

Embedded Go Online Service

For low-latency deployments, Feast bundles a Go-based online features service that can be embedded directly inside a Python process. Source: sdk/python/feast/embedded_go/online_features_service.py. This path is commonly used when the host application already runs Python and wants to avoid an extra network hop.

Server Topology and Request Flow

The diagram below shows how a client request is routed through the available servers, the stores they touch, and where transformations are evaluated.

flowchart LR
    Client[Client / Model] -->|REST/gRPC| FS[Python Feature Server]
    Client -->|MCP| MCP[MCP Server]
    FS --> Online[(Online Store)]
    FS --> TS[Transformation Server]
    FS --> Reg[(Registry)]
    MCP --> FS
    Client -->|Historical| OFS[Offline Feature Server]
    OFS --> Offline[(Offline Store)]
    Client -->|Browse| RS[Registry Server]
    RS --> Reg
    Embedded[Embedded Go Service] --> Online

Feature servers read feature view definitions from the registry, fetch latest values from the online store, and delegate any on-demand transformations to the transformation server. Source: sdk/python/feast/feature_server.py. Offline retrieval flows through the offline server, which queries the offline store and writes point-in-time-correct datasets. Source: sdk/python/feast/offline_server.py.

Compute Engines and the DAG Abstraction

Feast models feature engineering as a Directed Acyclic Graph (DAG). The DAG module lives under sdk/python/feast/infra/compute_engines/dag/ and exposes five core abstractions:

• context.py – ExecutionContext for managing per-feature-view execution state.
• node.py – DAGNode representing an individual operation.
• value.py – DAGValue for data passed between nodes.
• model.py – data classes such as DAGFormat.
• plan.py – ExecutionPlan that runs the graph.

Source: sdk/python/feast/infra/compute_engines/dag/README.md. This abstraction lets the same logical plan run on different compute engines (local, Ray, Spark) without changing feature view definitions.

Transformation Pipeline

The transformation pipeline describes how raw inputs become features at retrieval time:

1. Definition – A FeatureView or BatchFeatureView declares one or more transformation fields. Recent releases added a mode field to the Transformation proto so that transformations are correctly serialized and persisted in the registry (v0.56.0). Source: GitHub release v0.56.0.
2. Packaging – The definition is bundled with the feature view and shipped to whichever server evaluates it.
3. Evaluation – At retrieval time the Python feature server forwards on-demand requests to the transformation server over gRPC. The transformation server returns computed values that are merged with the online store response. Source: sdk/python/feast/transformation_server.py.
4. Static artifacts – Templates such as pytorch_nlp demonstrate pre-loading lookup tables and small models at feature server startup, so each request avoids cold-start cost. Source: sdk/python/feast/templates/pytorch_nlp/README.md.

Operational Notes

The Feast Operator simplifies running these servers on Kubernetes by providing a FeatureStore CRD with persistence, registry topology, security, and batch job settings. The persistence guide (link in the operator README) covers file-based versus DB-backed online, offline, and registry stores. Source: infra/feast-operator/README.md.

Community-reported issues worth noting: in v0.64.0 the RedisOnlineStore gained an async_supported property, and the operator CRD was updated with additional feast init templates. A separate issue (#6488) describes get_online_features dropping all but the first join key on remote stores, which is relevant when validating online retrieval behavior.

See Also

• README.md – project overview and roadmap.
• infra/feast-operator/README.md – Kubernetes operator and FeatureStore CRD.
• java/serving/README.md – Java feature server developer guide.
• sdk/python/feast/templates/ray/README.md – Ray compute engine template.

Related Pages

Related topics: Feast Overview, Architecture, and Core Concepts, Feature Servers, Compute Engines, and Transformation Pipeline

Deployment, Kubernetes Operator, Web UI, and Operations

Overview

Feast ships with several first-class mechanisms for production deployment and day-2 operations: a Kubernetes Operator that reconciles FeatureStore custom resources, a composable set of Helm charts for the core components, a Python Web UI for browsing feature repositories, and a CLI that drives apply/materialize/serve workflows. Source: README.md.

The recommended path to production is to install the Operator once per cluster and then declare feature stores declaratively as Kubernetes resources. The Operator currently uses the 0.64.0 chart version, as reflected in appVersion: v0.64.0 badges on the published sub-charts (Source: infra/charts/feast/charts/feature-server/README.md, infra/charts/feast/charts/transformation-service/README.md).

Feast Kubernetes Operator

The Operator lives under infra/feast-operator/ and exposes a single CRD, FeatureStore, defined in feast.dev_featurestores.yaml. A FeatureStore spec can declare feastProjectDir (git clone or feast init template), persistence choices (file path, PVC, or DB for offline/online/registry), serving settings (workers, log level, Prometheus metrics, MCP), registry topology (local, remote, cross-namespace via feastRef), security (RBAC roles vs OIDC), and batch/jobs settings (batchEngine ConfigMap, cronJob for materialization) (Source: infra/feast-operator/README.md).

The full CRD surface is documented in the project's docs/api/markdown/ref.md, and the canonical types are defined in Go under infra/feast-operator/api/v1/featurestore_types.go (Source: infra/feast-operator/config/crd/bases/feast.dev_featurestores.yaml). A guided quickstart is provided in examples/operator-quickstart/ with notebooks for install, demo, and uninstall steps (Source: examples/operator-quickstart/README.md).

The operator bundles the missing feast init templates and persistence documentation, addressing a long-standing operator-to-CLI parity gap (cf. the v0.64.0 release notes: "Add missing feast init templates to operator CRD and enhance persistence documentation") (Source: v0.64.0 release notes).

flowchart LR
  User[User / Platform Team] -->|kubectl apply| CR[FeatureStore CR]
  CR --> Op[Feast Operator Controller]
  Op -->|reconciles| FS[FeatureStore Pods<br/>online + offline + registry]
  Op -->|provisions| PVC[(PVC / DB / Object Store)]
  FS -->|gRPC / REST| Client[Feast Python/Go/Java SDK]
  Client -->|get_online_features| Online[(Online Store<br/>Redis, etc.)]
  Client -->|get_historical_features| Offline[(Offline Store<br/>BigQuery, Snowflake, ...)]

Helm Charts and Image Topology

The umbrella chart infra/charts/feast/ composes three sub-charts — feature-server (the Java online serving service), transformation-service (the gRPC on-demand transformation server), and supporting persistence objects — each pinned to 0.64.0. The feature-server chart exposes application-override.yaml and application-secret.yaml precedence rules, allowing operators to layer overrides via ConfigMap or Secret (Source: infra/charts/feast/charts/feature-server/README.md). The transformation chart exposes envOverrides, podLabels, replicaCount, nodeSelector, and service.grpc.port/nodePort for fan-out tuning (Source: infra/charts/feast/charts/transformation-service/README.md).

For developers who prefer raw Helm without the Operator, the standalone infra/charts/feast-feature-server/ chart is maintained separately (Source: infra/charts/feast-feature-server/values.yaml). A working Redis + MinIO end-to-end walkthrough is available in examples/python-helm-demo/, including kubectl port-forward recipes and the REDIS_PASSWORD extraction pattern from the Bitnami Redis secret.

Feast Web UI

The experimental Web UI (ui/) is a Create React App that can be launched in three ways: through the feast ui CLI to inspect the local feature repository, by importing @feast-dev/feast-ui as a module into a host React application, or by running the full standalone build (Source: ui/README.md). When imported as a module, the host app supplies a projects-list.json describing the repositories to render; optional peer dependencies are @elastic/eui and @emotion/react for theming.

Community issues track regressions across upgrades — e.g. the UI rendered incorrectly after a 0.63.0 → 0.64.0 demo upgrade (issue #6539). Operators rolling forward should pin the UI version and re-validate the demo flow against the published 0.64.0 charts.

Operations: CLI, Serving, and RBAC

The Python CLI in sdk/python/feast/cli/cli.py is the operational entrypoint: it implements feast init, feast apply, feast materialize, feast materialize-incremental, feast serve, and feast ui. The feast serve command launches the Python feature server, while the Java serving module under java/serving/ provides the gRPC/HTTP online serving implementation packaged as an executable jar via Maven (mvn -f java/serving/pom.xml package) (Source: java/serving/README.md, sdk/python/feast/cli/cli.py). Recent v0.64.0 work added an async_supported property to RedisOnlineStore to unblock async materialization paths (Source: v0.64.0 release notes).

For multi-tenant deployments, RBAC authorization can be enforced at the registry boundary. The examples/rbac-remote/ example ships three personas — feast-admin-sa, feast-user-sa, and feast-unauthorized-sa — with corresponding roles (feast_admin_permission, feast_user_permission, feast_unauthorized_permission) and an auth_type: kubernetes block in feature_store.yaml (Source: examples/rbac-remote/README.md). Common production failure modes discussed in the community include dropped join keys on remote online stores (issue #6488) and missing readiness checks on the REST registry, both of which are addressed by targeted fixes in recent releases (Source: v0.61.0 release notes).

See Also

• Feast main README
• Feast Operator configuration guides
• Java Serving developer guide
• Operator quickstart examples
• RBAC remote example

Doramagic Pitfall Log

Found 8 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/feast-dev/feast/issues/6488

2. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/feast-dev/feast

3. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/feast-dev/feast/issues/6539

4. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/feast-dev/feast

5. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/feast-dev/feast

6. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/feast-dev/feast

7. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/feast-dev/feast

8. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/feast-dev/feast

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using feast with real data or production workflows.

• 0.63.0 -> 0.64.0: UI breaks in demo - github / github_issue
• Support zoned datetime feature type - github / github_issue
• get_online_features on remote stores drops all join keys but the first - github / github_issue
• v0.64.0 - github / github_release
• v0.63.0 - github / github_release
• v0.62.0 - github / github_release
• v0.61.0 - github / github_release
• v0.60.0 - github / github_release
• v0.59.0 - github / github_release
• v0.58.0 - github / github_release
• v0.57.0 - github / github_release
• v0.56.0 - github / github_release