This project should strictly addere to SemVer and Conventional commits standards

[manast]

What is the problem this feature would solve?

In order to be a good citizen in the NodeJS ecosystem, it is important to adhere to the best practices that have been collectively developed for more than a decade.

First of all, now that Bun has reached 1.0, the SemVer is crucial to know if the release is a bugfix release, a new feature release, or incorporates breaking changes. This is all documented in the SemVer standard, I do not see any good reason not to follow it. It creates order where otherwise there would be chaos and frustration: https://semver.org/

Secondly, for a project so big and ambitious as this one, it is expected to have a better standard for the commit messages, so that it is easy to follow the changes, what is affected by every commit, and so on. That is why in Node we mostly use the conventional commit standard: https://www.conventionalcommits.org/en/v1.0.0/ There are tools to help enforce this standard such as commitlint

What is the feature you are proposing to solve the problem?

Easier to follow and understand changes, review code, produce changelogs, serve as the basis for deciding when to upgrade, and so on.

What alternatives have you considered?

No response

[shellscape]

I'm going to agree with this as well. Not adhering to semver and operating within the Node ecosystem is an unusually poor choice for this project. (Not that this has impact, but it's part of the user story) I've been watching Bun closely and was gearing up to swap this into a few places. However, if I can't count on strict versioning for confidence in updates, I'll be walking back those plans. I'm glad I saw this pop up on Twitter.

[rivertam]

I struggle to imagine where this would impact anyone. SemVer is mostly important for libraries/dependencies managed by package managers, which bun isn't; bun is primarily an executable which is installed to your system path. The bun API is in use by user code, but the user code itself is unlikely to specify the bun version. Even if it does specify the bun version, I truly struggle to imagine a user for whom this has any bearing. Maybe in 2.1 bun will introduce a shared object library version of itself, so it can be embedded into other languages, but at that point the fact that bun did not strictly adhere to SemVer during the 1.0 phase can't be relevant, can it?

Can someone give a specific user story where this would matter?

[manast]

@rivertam so in your production system, you just install whatever last version of bun is available at the time of deployment?

[rivertam]

I don't have a production system written using bun, but in systems where I rely on node, I install node in a dockerfile at a specific version, and I'd do the same with bun (or any tool that is accessed as an executable or set of executables). For example, FROM oven/bun:1.0.6-slim. I don't understand how strict SemVer adherence is necessary in order to pin the bun version for production projects.

[manast]

@rivertam because the day you want/need to upgrade due to a bugfix or a security patch you want to know how disruptive that upgrade will be. If it is a patch release you may just need to run some tests with the new version and quite likely nothing else would need to be done. If new features or breaking changes come in in the patch version you may be for a hard ride before you can make the upgrade on your production release. At the time being we do not even have a proper changelog, so you would need to check the commit list between versions to get an idea of what has changed... this will need to improve in order to get any serious acceptance when the hype dust has settled.

[manast]

Btw, I am quite surprised that there are so many thumb-downs, but no other counterargument than "it is not needed". See, it is not just a good practice that makes life easier for a DevOps, it is actually quite important to bring quality to the project. If you are adding new features in every micro release, mixed with some bugfixes and breaking changes, you virtually do not have any good measure of quality, as you know, adding new features implies a higher risk of introducing new bugs, that's why most people would not upgrade on the next minor/major release, and instead wait for some micro releases to address the most important bugs before you take the step of upgrading your runtime. For the people against SemVer, what is their alternative? just increase the versions ad-hoc? I am quite sure that whatever direction this project takes, some policy for naming versions will need to be taken sooner or later.

[jasongitmail]

Those thumbs down could be because of conventional commits in the title, which arguably is a style and workflow preference for the developers of bun.

My 👍 is for the semver aspect, bc it is courteous to end users of Bun. It provides useful info without downsides.

[manast]

@jasongitmail It does not need to be the conventional commit standard, but it is pretty difficult to implement SemVer in a project as large as this one, with so many contributors and commits per release without having a standardized commit format that helps you decide which version number should the next release get. Ideally of course with automatic releases... this just saves time for everybody and results in a much better product in my opinion.

[cayter]

Btw, I am quite surprised that there are so many thumb-downs, but no other counterargument than "it is not needed". See, it is not just a good practice that makes life easier for a DevOps, it is actually quite important to bring quality to the project. If you are adding new features in every micro release, mixed with some bugfixes and breaking changes, you virtually do not have any good measure of quality, as you know, adding new features implies a higher risk of introducing new bugs, that's why most people would not upgrade on the next minor/major release, and instead wait for some micro releases to address the most important bugs before you take the step of upgrading your runtime. For the people against SemVer, what is their alternative? just increase the versions ad-hoc? I am quite sure that whatever direction this project takes, some policy for naming versions will need to be taken sooner or later.

I am honestly not surprised. We tried migrating our production Remix app with Vitest to use Bun a few weeks back after the v1 announcement and realised there's a lot of issues which led us to have to put on hold of Bun usage on production.

Given this experience, I am not surprised if Bun is mainly used for weekend/side projects at the moment, or at best for installing deps + running unit tests that don't require module mocking. That's why there are ppl okay with non-strict SemVer as it's not really causing issues to them. With that said, I'm happy to be proven wrong by ppl who are using Bun on production that have real paying customers.

Our plan to migrate again after the experience above would be end of Q1 next year, but given the incrementing # of Github issues and vague SemVer releases, I think we will have to stick to NodeJS + tsx for a bit longer as we can't afford to mess our customers' payroll processing, it's real money we're talking about.

[Jarred-Sumner]

We will do SemVer versioning once Windows builds happen regularly (which @paperdave is working on now). It’s a very reasonable thing to ask of a >= 1.0 project.

I think that the Node policy of backporting fixes to older versions is unlikely for a long time (if ever) for us though. We are a small team. Instead, we would prefer to avoid breaking changes or otherwise creating reasons for companies to not upgrade

[goulashsoup]

I don't even properly understand the counterarguments: I see a huge risk as a developer if bun doesn't adhere to SemVer.

I imagine the situation where I create automatic builds based on a bun Dockerfile that are used in automatic deployments, I can NEVER be sure if there aren't any breaking changes leading to the App not working which could result in financial losses when the App relies on financial transactions working. To mitigate this, all dev teams have to put a lot of effort into checking possible breaking changes and into testing the Apps before release.

Although probably Apps with updated dependencies "should" always be tested before being deployed, it makes a difference if there are "surprising" breaking changes...

I also suggest making v1 already an LTS version, it will be a good "selling point" for new projects to start with bun...

@Jarred-Sumner Is bun now using SemVer? Can this issue be closed?

[egabai]

Any updates on this?