@powerhousedao/academy 2.5.0-dev.10 → 2.5.0-dev.11

package/CHANGELOG.md

@@ -1,3 +1,13 @@
+## 2.5.0-dev.11 (2025-06-07)
+
+### 🚀 Features
+
+- **connect:** updated diff-analyzer processor ([ce5d1219f](https://github.com/powerhouse-inc/powerhouse/commit/ce5d1219f))
+
+### ❤️ Thank You
+
+- acaldas
+
 ## 2.5.0-dev.10 (2025-06-06)
 
 ### 🚀 Features

package/docs/academy/02-MasteryTrack/05-Launch/02-PublishYourProject.md

@@ -202,15 +202,79 @@ If you're publishing a package under a scope (like @your-org/my-package), you mi
 }
 ```
 
-For the actual publishing step, run the following command to publish your project to the npm registry:
+### 2.1 Versioning, Tagging, and Publishing Your Package
+
+Before publishing, it's crucial to version your package correctly and tag the release in your Git repository. This helps track changes and allows users to depend on specific versions.
+
+**1. Versioning with PNPM**
+
+Use the `pnpm version` command to update your package version according to semantic versioning rules (`patch` for bugfixes, `minor` for new features, `major` for breaking changes). This command will:
+- Update the `version` in your `package.json`.
+- Create a Git commit for the version change.
+- Create a Git tag for the new version (e.g., `v1.0.1`).
+
+```bash
+# For a patch release (e.g., from 1.0.0 to 1.0.1)
+pnpm version patch
+
+# For a minor release (e.g., from 1.0.1 to 1.1.0)
+pnpm version minor
+
+# For a major release (e.g., from 1.1.0 to 2.0.0)
+pnpm version major
+```
+Take note of the new version tag created (e.g., `v1.0.1`), as you'll need it in the next step.
+
+**2. Pushing Changes to Git**
+
+Next, push your commits and the new version tag to your remote Git repository:
+
+```bash
+# Push your current branch (e.g., main or master)
+# Replace 'main' with your default branch name if different
+git push origin main
+
+# Push the specific tag created by pnpm version
+# Replace vX.Y.Z with the actual tag name (e.g., v1.0.1)
+git push origin vX.Y.Z
+```
+The specific tag name (e.g., `v1.0.1`) is usually output by the `pnpm version` command. Pushing the specific tag is recommended to avoid unintentionally pushing other local tags.
+
+Alternatively, to push all new local tags (use with caution):
+```bash
+# git push --tags
+```
+
+**3. Understanding Git Tags vs. NPM Distributor Tags**
+
+It's important to distinguish between Git tags and NPM distributor tags (dist-tags):
+
+-   **Git Tags**: These are markers in your Git repository's history. They are primarily for developers to pinpoint specific release versions in the codebase (e.g., `v1.0.0`, `v1.0.1`). The `pnpm version` command creates these.
+-   **NPM Distributor Tags (dist-tags)**: These are labels used by the NPM registry to point to specific published versions of your package. Common NPM tags include:
+    -   `latest`: This is the default tag. When someone runs `pnpm install my-package`, NPM installs the version tagged as `latest`.
+    -   `beta`, `next`, `alpha`: Often used for pre-release versions.
+    When you publish a package without specifying an NPM tag, it usually gets the `latest` tag by default.
+
+**4. Publishing to NPM**
+
+Now you are ready to publish your package to the NPM registry. Ensure you are logged into NPM (the `npm login` command shown in previous steps should be used, or `pnpm login` which is an alias).
+
+```bash
+pnpm publish
+```
+This command will publish the version of your package that is currently specified in your `package.json`. By default, this will also set the `latest` NPM dist-tag for this version.
+
+If your package is scoped (e.g., `@your-org/my-package`) and intended to be public, ensure your `package.json` includes the `publishConfig` shown earlier. If this is not set in `package.json` (and your package is scoped), you might need to use:
 ```bash
-npm publish
+pnpm publish --access public
 ```
 
-Optionally, if you are publishing a scoped package and you want it public, run:
+You can also publish a version to a specific NPM dist-tag. For example, to publish a beta version:
 ```bash
-npm publish --access public
+# Ensure your package.json version reflects the beta (e.g., 1.1.0-beta.0)
+pnpm publish --tag beta
 ```
+This is useful for testing releases before making them `latest`.
 
 Now let's verify that the package(s) get published in the package repository, next to pre-existing packages that you might have been publishing before.
 

package/docs/academy/06-ComponentLibrary/03-Scalar-Components/01-phid-field.mdx

@@ -43,7 +43,7 @@ import { Tabs, TabItem } from '@theme/Tabs';
     - **Error Message Example:** "Invalid PHID format. Please check the document ID, branch, or scope."
 </details>
 
-The following is a the UI component for the PHID field and scalar in a storybook.
+The following is the UI component for the PHID field and scalar in a storybook.
 We use Storybook as our component development environment. 
 It allows us to build and test UI components in isolation, making it easier to develop, test, and document reusable components.
 In our stories you'll find first find a basic UI implementation example of the component, followed by the component's properties, events, and validation options.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@powerhousedao/academy",
-  "version": "2.5.0-dev.10",
+  "version": "2.5.0-dev.11",
   "homepage": "https://powerhouse.academy",
   "repository": {
     "type": "git",