You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
4. Make sure your token meets our requirements (see [CONTRIBUTING.md](./CONTRIBUTING.md))
70
+
5. Run tests locally: `npm test`
71
+
6. Create a Pull Request
72
+
73
+
**Note**: The timestamp is automatically updated when the deployment workflow runs after a release is published, marking the deployment time to GitHub Pages.
74
+
75
+
### Publishing a New Version
76
+
77
+
After merging changes to `main`:
78
+
79
+
1. Create a GitHub Release with a tag matching the version in `tokens/token-list.json` (e.g., `v1.2.0`)
80
+
- The tag must use the format `v<MAJOR>.<MINOR>.<PATCH>` (e.g., `v1.2.0`)
81
+
- Ensure the release tag matches the version in your token list exactly
82
+
2. The deployment workflow will automatically:
83
+
- Update the timestamp to the current deployment time
84
+
- Preserve the new version as a historical snapshot in `versions/`
85
+
- Deploy all versioned files to GitHub Pages
86
+
- Make the new version available at all URL patterns
87
+
88
+
Monitor deployment progress in the [Actions tab](https://github.com/RequestNetwork/request-token-list/actions/workflows/deploy.yml) of this repository.
89
+
90
+
**Note**: The workflow does not validate that the release tag matches the version in `tokens/token-list.json`. If they don't match, the deployed version will use the version from the JSON file, not the release tag. Always ensure they match to avoid confusion.
0 commit comments