search

fate-srd / fate-product-list

A list of Fate RPG products
3 stars 3 forks source link

Add simple semantic versioning #10

Open amazingrando opened 4 days ago

amazingrando commented 4 days ago

By adding version numbers to this repo, other projects can know when this has been updated. I would find this useful for the Fate SRD product list page.

What do I mean by simple? Every change that is merged into main could increment it.

If we wanted to get fancy, we could change the major number (1.0.0) each time a product is added or removed and a minor number (0.1.0) for other edits. Enforcing this fancy version would require effort.

johnhelmuth commented 3 days ago

I think a simple incrementing integer would be sufficient. An alternative might be just to use the date. I am open to any scheme though.

I haven't set up any github actions, just skimmed the docs... seems like it might be possible to set up an action to add a git tag immediately after a merge to main.

I'll do a little more research this weekend on getting that set up. We could have the action make the decision to do the minor v. major version change based on the number of lines difference between the previous version the new version.

amazingrando commented 3 days ago

Incrementing the version number in package.json would be great, since I have it installed as a package in the Fate SRD repo.

johnhelmuth commented 3 days ago

Got it. I had completely skipped over the package.json as I was not expecting any JS code... but this is how you are getting this repo into your other codebase, which makes sense. I hadn't connected those dots until just now.

I will include that as a requirement in whatever we work out for this. More to come after this weekend.

szabba commented 1 day ago

If we wanted to get fancy, we could change the major number (1.0.0) each time a product is added or removed and a minor number (0.1.0) for other edits. Enforcing this fancy version would require effort.

Thinking about this like a semvered API I'd expect something closer to:

Since the CSV has a header I think it's feasible to treat column reodering as a patch change.

Intuition tells me either of those approaches to "which part of the number do we bump" is probably overkill.

johnhelmuth commented 11 hours ago

@amazingrando Would you want the version number to bump when a commit/merge with the required changes is pushed to main, or would you rather have a formal GitHub release trigger it?

I'm thinking that the best way to implement this is by adding some scripts to the repo to handle these cases, and trigger them via configuration in package.json... npm version does the version number change, including handling git tagging... and we can add some glue code to implement the logic about determining which level of the semver version to bump.

johnhelmuth commented 11 hours ago

I agree with @szabba that the changes in columns should trigger a major or minor version bump, as removing a column is more of a "breaking change" while adding a column is something that code that consumes this data can easily handle.