Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Use latest version in demos #61

Merged
merged 2 commits into from
Apr 18, 2023
Merged

Use latest version in demos #61

merged 2 commits into from
Apr 18, 2023

Conversation

jcbhmr
Copy link
Contributor

@jcbhmr jcbhmr commented Apr 13, 2023

No description provided.

@jcbhmr
Copy link
Contributor Author

jcbhmr commented Apr 13, 2023

@spenserblack ready for review

@jcbhmr
Copy link
Contributor Author

jcbhmr commented Apr 13, 2023

personal preference: i like to, as the maintainer, modify the package.json version field, find-and-replace v1.5.9 with v1.6.0 MANUALLY on the main branch as a bump commit or similar. but that's just how i do things in my own repos.

i suggest either a) add a note to contributing.md to say "dont forget to bump the version" or b) remember to bump version via find-and-replace JUST BEORE RELEASING (requires manually) -- using vscode makes this wicked easy. you can even exclude specific files like changelogs or docs that you want to stay locked to version tags if need be. or do the reverse and find-replace only in specific files.

README.md Outdated
- uses: spenserblack/actions-wiki@v0.1.1
- uses: spenserblack/actions-wiki@v0.2.0
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be easiest on us to just say @<commit-ish> or @main, and add a comment with a URL to our tags.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it should be spenserblack@v1 or vN like most other actions to fit the existing ecosystem convention stuff

also @main is sometimes broken cause its the in-progress dev-state, but @vN or @vN.N.N are 100% legit

ideally it'd be @vN like @v1 when we do get to v1 (whenever that happens 🙄) so that it is a general good idea to pin to major versions like that. and also that's what most existing actions do

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One bonus of @<commit-ish> or @vN (that's a literal N, not a placeholder), is that it forces a new user to look at our releases instead of just copying and pasting, since it's invalid 😆

@jcbhmr
Copy link
Contributor Author

jcbhmr commented Apr 17, 2023

personal preference: i like to, as the maintainer, modify the package.json version field, find-and-replace v1.5.9 with v1.6.0 MANUALLY on the main branch as a bump commit or similar. but that's just how i do things in my own repos.

i suggest either a) add a note to contributing.md to say "dont forget to bump the version" or b) remember to bump version via find-and-replace JUST BEORE RELEASING (requires manually) -- using vscode makes this wicked easy. you can even exclude specific files like changelogs or docs that you want to stay locked to version tags if need be. or do the reverse and find-replace only in specific files.

actually I rescind this since it doesn't apply here 😆 oops

I was thinking if there was a field in the action.yml like

name: @spenserblack wiki action
description: awesome wiki action here!
version: 0.2.0 # I hallucinated that this existed... 🤦

instead, the only think you need to change is on MAJOR VERSION bumps in the readme (hopefully) from v1 to v2 or whatever.

@jcbhmr jcbhmr requested a review from spenserblack April 18, 2023 20:40
@spenserblack spenserblack merged commit 41eed25 into spenserblack:main Apr 18, 2023
@jcbhmr jcbhmr deleted the patch-4 branch April 18, 2023 22:48
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants