Version 6.6.0 introduces a breaking change despite being tagged as a minor version

[SmashingQuasar]

Bug description

Hello,

We just upgraded to version 6.6.0 and noticed that all of our builds and development environments fell apart.
This is due to the change (that is actually flagged as a breaking change in the patch note of version 6.6.0) regarding the preview feature for prisma schema folders.

While it is fine to introduce breaking change, it would be preferable to follow the SemVer standard. This is especially true in JavaScript environments where most of the time, your package manager will upgrade to the next minor version without explicit approval.

As per SemVer, all breaking changes must trigger a major version.

It may seem like a small problem but this can have dire cascading effects on production environments, which is why there is a standard to prevent this kind of problem. Since Prisma is backed by a company with complete development cycles, it would be much appreciated to have a better tracking of breaking changes in regard to SemVer.

I used the bug flag here as this creates major disruption in existing pipelines and builds. It could recategorised differently but I don't feel like it is a feature request.

Severity

⚠️ Major: Breaks core functionality (e.g., migrations fail)

Reproduction

Setting your version to ^6.5.0 in your package.json and running pnpm install or yarn install will trigger the automatic installation of version 6.6.0 which will break existing schema structure.

Note that ^6.5.0 is the default syntax used by package managers when doing pnpm install or yarn install.

Expected vs. Actual Behavior

Version 6.6.0 should be tagged version 7.0.0 regardless of commercial concerns as this is a technical library for technical purposes.

Frequency

Consistently reproducible

Does this occur in development or production?

Both development and production

Is this a regression?

N/A

Workaround

N/A

Prisma Schema & Queries

The following prisma folder structure will break between version 6.5.0 and 6.6.0:

prisma/
├── migrations/
│   └── any-migration.sql
└── schema/
    └── schema.prisma

Prisma Config

// Add your `prisma.config.ts`

Logs & Debug Info

// Debug logs here

Environment & Setup

• OS: Debian 12
• Database: PostgreSQL
• Node.js version: 22.x

Prisma Version

6.6.0

[Stadly]

For opt-in preview features, Prisma does not follow SemVer.

Here is a brief overview of how Prisma ORM's follows SemVer:

1. Breaking changes in stable surface (i.e. General Availability) will only be introduced in new MAJOR releases.
2. Breaking changes can still be rolled out in MINOR but only for opt-in Preview and Early Access features that are not active by default (e.g. via a Preview feature flag or a specific opt-in option or new CLI command).
3. Opt-in breaking changes, i.e. Preview and Early Access, released in MINOR, will only be promoted to General Availability (no requirement for opt-in) in new MAJOR releases.

Source: https://www.prisma.io/docs/orm/more/releases#versioning

[SmashingQuasar]

The problem with that, is that the default behaviour of package managers is to update minor versions automatically.
I understand the need for a commercial version, product managers and marketing are always after engineers to have a commercial version.

Prisma is entirely an engineers focused product. It should follow engineers conventions.

If Prisma wants to keep that logic, there is a solution that is unsatisfactory but would alleviate the problem. Prisma could follow the same logic Node.js does. Even versions are stable, odd versions aren't. I don't like it, but at least it does not suddenly break all existing pipelines because a new minor version was published.

That would allow Prisma to keep working the same way, but us users to be reassured that we aren't going to encounter unexpected issues out of the blue.

Preview features aren't just preview features. Prisma makes them available so users can play with them and test them. If we cannot have any reassurance that using preview features is not going to make our solution fall apart within a minor version, it means fewer people will try preview features and it will lower the quality of the product.

[sanny-io]

@SmashingQuasar

That would allow Prisma to keep working the same way, but us users to be reassured that we aren't going to encounter unexpected issues out of the blue.

Users are gonna continue encountering broken builds as long as they aren't pinning their dependencies. The underlying problem isn't actually related to Prisma at all, and isn't going to go away regardless of what the Prisma team does. Today it was Prisma. Tomorrow it's gonna be some other package they didn't pin.

I'm not so sure Prisma would benefit from the versioning changes you've suggested. Restricting opt-in preview breaking changes to major versions just seems a bit much, especially when you consider that they aren't recommended for production use to begin with.

With that said, clearly users were caught off guard by this. I would prefer that users be cautioned in the documentation that they should pin Prisma to an exact version, or at least a specific major and minor if they're ok with the risk of a patch going wrong.

[SmashingQuasar]

@SmashingQuasar

That would allow Prisma to keep working the same way, but us users to be reassured that we aren't going to encounter unexpected issues out of the blue.

Users are gonna continue encountering broken builds as long as they aren't pinning their dependencies. The underlying problem isn't actually related to Prisma at all, and isn't going to go away regardless of what the Prisma team does. Today it was Prisma. Tomorrow it's gonna be some other package they didn't pin.

I'm not so sure Prisma would benefit from the versioning changes you've suggested. Restricting opt-in preview breaking changes to major versions just seems a bit much, especially when you consider that they aren't recommended for production use to begin with.

With that said, clearly users were caught off guard by this. I would prefer that users be cautioned in the documentation that they should pin Prisma to an exact version, or at least a specific major and minor if they're ok with the risk of a patch going wrong.

I agree with the reasoning. The problem is multifaceted. Package managers are correctly following SemVer, but this creates situations like this one.

Pinning dependencies works, but it means circumventing an issue that arises from personal preference on Prisma's side.

The way Prisma implements SemVer is not compliant with SemVer. It's a standard that has parts that are up to the users, like the numbering system, but the rules of what is or isn't worth a major or minor is not up to personal preference.

SemVer isn't without flaws. It would need a version 3 to help with preview features.

I think the worst part about this version 6.6.0 is not that it broke existing code. It's that it did just because Prima decided to change their personal view on how this needs to be ordered.
The underlying feature of being able to use folders is probably one of the most requested. It's absolutely paramount if you want to work with any large scale application.
This preview feature was in fact quite mandatory to use. Entirely flipping the logic on itself was unnecessary and could have waited for the next major.

It was a change made too hastily without considering the implications of such a change.

This is why we have SemVer. It protects us from breaking existing client applications by enforcing a clear and concise standard. This is why if you start adapting SemVer, you will inevitably create poor situations for your clients.