Update Readme and Release Docs

README.md

@@ -1 +1,107 @@
-# python-tfe
+# HCP Terraform and Terraform Enterprise **Python** Client (pyTFE)
+
+[![PyPI](https://img.shields.io/pypi/v/pytfe.svg)](https://pypi.org/project/pytfe/)
+[![Python Versions](https://img.shields.io/pypi/pyversions/pytfe.svg)](https://pypi.org/project/pytfe/)
+[![CI](https://github.com/hashicorp/python-tfe/actions/workflows/ci.yml/badge.svg)](https://github.com/hashicorp/python-tfe/actions/workflows/ci.yml)
+[![License](https://img.shields.io/github/license/hashicorp/python-tfe.svg)](./LICENSE)
+[![Issues](https://img.shields.io/github/issues/hashicorp/python-tfe.svg)](https://github.com/hashicorp/python-tfe/issues)
+
+The official **Python** API client for [HCP Terraform and Terraform Enterprise](https://www.hashicorp.com/products/terraform).
+
+This client targets the [HCP Terraform V2 API](https://developer.hashicorp.com/terraform/cloud-docs/api-docs).
+As Terraform Enterprise is the self-hosted distribution of HCP Terraform, this client supports both **HCP Terraform** and **Terraform Enterprise** use cases. In this repository and API, we refer to the platform generically as *Terraform Enterprise* unless a feature is explicitly called out as only supported in one or the other (rare).
+
+## Version Information
+
+We follow Semantic Versioning. During the initial alpha period we use `0.y.z`:
+- **Minor** (`0.y.z → 0.(y+1).z`): new, backwards-compatible features and enhancements.
+- **Patch** (`0.y.z → 0.y.(z+1)`): bug fixes and performance improvements.
+- Occasionally, a function signature change that fixes incorrect behavior may appear in a minor version.
+
+## Example Usage
+
+Construct a new **pyTFE** client, then use the resource services on the client to access different parts of the Terraform Enterprise API. The following example lists all organizations.
+
+### (Recommended) Using explicit config
+
+```python
+import os
+from pytfe import TFEClient, TFEConfig
+
+config = TFEConfig(
+    host="https://tfe.local",
+    token="insert-your-token-here",
+    retry_server_errors=True,
+    timeout=30.0,
+    user_agent="example-app/0.1 pytfe/0.1",
+)
+
+client = TFEClient(config)
+
+orgs = client.organizations.list()
+for org in orgs.items:
+    print(org.name)
+```
+
+### Using the default config with environment variables
+
+The default configuration reads the `TFE_ADDRESS` and `TFE_TOKEN` environment variables.
+
+1. `TFE_ADDRESS` — URL of an HCP Terraform or Terraform Enterprise instance. Example: `https://tfe.local`  
+2. `TFE_TOKEN` — An [API token](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/api-tokens) for the HCP Terraform or Terraform Enterprise instance.
+
+
+Environment variables are used as a fallback when `host` or `token` are not provided explicitly:
+
+#### Using the default configuration
+```python
+from pytfe import TFEClient, TFEConfig
+
+# Equivalent to providing no values; falls back to env vars if set.
+client = TFEClient(TFEConfig())
+orgs = client.organizations.list()
+for org in orgs.items:
+    print(org.name)
+```
+
+#### When host or token is empty
+```python
+from pytfe import TFEClient, TFEConfig
+
+config = TFEConfig(address="", token="")
+client = TFEClient(config)
+
+orgs = client.organizations.list()
+for org in orgs.items:
+    print(org.name)
+```
+
+## Documentation
+
+- API reference and guides (SDK): **coming soon**  
+- Terraform Enterprise API: https://developer.hashicorp.com/terraform/enterprise/api-docs
+
+## Examples
+
+See the [`examples/`](./examples) directory for runnable snippets covering common workflows (workspaces, variables, configuration versions, runs/plans/applies, state, agents).
+
+## Running tests
+
+See [`TESTS.md`](./docs/TESTS.md). Typical flow:
+
+```bash
+pip install -e .[dev]
+make test
+```
+
+## Issues and Contributing
+
+See [`CONTRIBUTING.md`](./docs/CONTRIBUTING.md). We welcome issues and pull requests.
+
+## Releases
+
+See [`RELEASES.md`](./docs/RELEASES.md).
+
+## License
+
+This project is licensed under the **MPL-2.0**. See [`LICENSE`](./LICENSE).

docs/CONTRIBUTING.md

@@ -0,0 +1 @@
+# Contributing to pytfe

docs/RELEASES.md

@@ -0,0 +1,45 @@
+## Release Process
+
+python-tfe can be released as often as required. Documentation updates and test fixes that only touch test files don't require a release or tag. You can just merge these changes into `main` once they have been approved.
+
+### Preparing a release
+
+Start by comparing the main branch with the last release in order to fully understand which changes are being released. Compare the last release tag with main. For each meaningful change, double check the following:
+
+1. Is the change added to CHANGELOG.md?
+2. Does the public package API follow all endpoint conventions, such as naming, pointer usage, and options availability? Once these are released, they are permanent in the current major release version.
+3. Are new features generally available in the HCP Terraform API? Or is there another considered reason to release them?
+
+Steps to prepare the changelog for a new release:
+
+1. Replace `# Unreleased` with the version you are releasing.
+2. Ensure there is a line with `# Unreleased` at the top of the changelog for future changes. Ideally we don't ask authors to add this line; this will make it clear where they should add their changelog entry.
+3. Ensure that each existing changelog entry for the new release has the author(s) attributed and a pull request linked, i.e `- Some new feature/bugfix by @some-github-user (#3)[link-to-pull-request]`
+4. Open a pull request with these changes titled `vX.XX.XX Changelog`. Once approved and merged, you can go ahead and create the release.
+
+### Creating a release
+
+1. [Create a new release in GitHub](https://help.github.com/en/github/administering-a-repository/creating-releases) by clicking on "Releases" and then "Draft a new release"
+2. Set the `Tag version` to a new tag, using [Semantic Versioning](https://semver.org/) as a guideline.
+3. Set the `Target` as `main`.
+4. Set the `Release title` to the tag you created, `vX.Y.Z`
+5. Use the description section to describe why you're releasing and what changes you've made. You should include links to merged PRs. Use the following headers in the description of your release:
+   - BREAKING CHANGES: Use this for any changes that aren't backwards compatible. Include details on how to handle these changes.
+   - FEATURES: Use this for any large new features added,
+   - ENHANCEMENTS: Use this for smaller new features added
+   - BUG FIXES: Use this for any bugs that were fixed.
+   - NOTES: Use this section if you need to include any additional notes on things like upgrading, upcoming deprecations, or any other information you might want to highlight.
+
+   Markdown example:
+
+   ```markdown
+   ENHANCEMENTS
+   * Add description of new small feature by @some-github-user (#3)[link-to-pull-request]
+
+   BUG FIXES
+   * Fix description of a bug by @some-github-user (#2)[link-to-pull-request]
+   * Fix description of another bug by @some-github-user (#1)[link-to-pull-request]
+   ```
+
+6. Don't attach any binaries. The zip and tar.gz assets are automatically created and attached after you publish your release.
+7. Click "Publish release" to save and publish your release.

docs/TESTS.md

@@ -0,0 +1 @@
+# Running tests