Bump Version

Analyze changes since the last version tag, determine the correct semver bump, and update all version references in the codebase.

Workflow

Step 1: Identify the Latest Version Tag

bash
1git tag --sort=-v:refname | head -1

The tag format is vMAJOR.MINOR.PATCH (e.g. v2.1.1).

Step 2: Analyze Changes Since the Last Tag

Gather the commit log and diff since the tag:

bash
1git log <tag>..HEAD --oneline
2git diff <tag>..HEAD --stat

Step 3: Classify the Semver Bump

Apply Semantic Versioning rules to the changes:

Context-specific guidance for this codebase:

• Adding a new custom function (e.g. GET_BALANCE_V2) → minor
• Adding a new chain or token to data.gs → minor
• Renaming or removing an existing custom function → major
• Changing the parameters of an existing custom function → major
• Fixing a bug in price fetching or balance calculation → patch
• Updating RPC URLs, API endpoints, or constants → patch
• Reformatting, linting, dependency bumps → patch

Present the analysis and proposed version to the user for confirmation before making changes.

Step 4: Update Version References

After the user confirms the bump, update exactly two locations:

1. package.json — version field

Update the "version" field to the new semver string (without the v prefix):

json
1"version": "X.Y.Z"

2. src/cryptfolio.gs — VERSION constant

The VERSION constant near line 13 is a monotonically incrementing integer string used by Google Apps Script for library deployment. Increment it by 1 from the current value:

js
1const VERSION = "N";  // increment N by 1

This is not the semver version. It is a separate deployment counter that always increments by exactly 1 regardless of the semver bump type.

Step 5: Summary

After updating, display a summary:

Version bump: vOLD -> vNEW
  package.json:       "OLD" -> "NEW"
  src/cryptfolio.gs:  VERSION "N" -> "N+1"

Do not create a git tag or commit. The user handles that separately.