Package.json version out of sync
mircea-pavel-anton opened this issue · 5 comments
Bug report
Describe the bug
The version in package.json is set to 0.0.0 instead of 1.6.4
Currently, this is intended behavior. From https://semantic-release.gitbook.io/semantic-release/support/faq#why-is-the-package.jsons-version-not-updated-in-my-repository: "By default, only the published package will contain the version, which is the only place where it is really required, but the updated package.json will not be pushed to the Git repository".
However, as you raised, this may be confusing, but are there any other practical drawbacks? We could consider pushing an updated package.json and maybe an updated CHANGELOG.md for every release. This would be pretty noisy though, since we make a release for every commit.
I see. I was unaware of that. The way I see it, it would be useful to have a version in the package.json file and an updated CHANGELOG.md as it would make very clear which features are supported in which versions.
Granted, I don't come from a javascript background and I just started using Node a few days ago, so I may be biased by the conventions of other languages.
That being said, I generally find it rather useful when projects I work with have a detailed changelog for every version. A good example, I think, would be defectdojo. They also release a few times per month and I don't think that it's noisy or redundant. I find it very helpful when assessing whether or not I have to upgrade or what would be the risk of upgrading, or even what are my options.
For example, say I am using version 1.6.0 of storage-js and the current version is 4.2.5. Maybe I need to upgrade because I require a new feature that is released in a later version, but since there is no changelog, I am not sure if upgrading to 1.8.0 is sufficient as to not run into breaking changes, or maybe 3.2.0 would be the minimum version required.
It would also allow supabase-js to clearly specify the specific version of each included package and be easily referenced.
It's not the changelog itself that would be noisy, but the commits, since there would be an extra commit for every human-made commit. https://github.com/supabase/storage-js/releases can serve for the purposes you described for an updated CHANGELOG.md? Though a human-curated CHANGELOG.md would be cleaner, and may be especially useful for supabase-js, not so much for the underlying packages since the Releases page for those is a decent alternative. We're considering a human-curated CHANGELOG.md and updating package.json.
Hmmm... I guess that's fair enough. The releases page is good enough to solve the issues I raised. While not the best option, it is certainly a good enough option.
I don't think the commits will be that noisy though, as they can simply be squashed together, in my opinion, so that a commit will contain the feature implementation as well as the changelog update and npm package version bump. Granted, it would be more work but still do-able.
I think this issue and the associated PR can be closed, considering what has been discussed. Do you agree?
The commits probably couldn't be squashed together, since we'd probably want them to be made by a bot instead of manually doing it along with the human-made PR. I'll close the PR but will leave this issue open for the time being until we decide whether or not to update the package.json version. It's possible we might not update the package.json version every time there's a change, due to the noise, but would maintain a human-curated CHANGELOG.md that's updated periodically.