Prisma is an ambitious project. To fulfill our vision of GraphQL as a universal query language, we have to increase the code base and significantly grow our list of core contributors. At the same time, Prisma is seeing a rapid increase in production deployments.
Our new release process is designed to deliver on two goals: First and foremost, every release of Prisma must be stable and have a smooth upgrade process. Secondly, Prisma is a young project and we have a lot of ground to cover. As such it is critical that our release process helps new and existing contributors to ship features fast.
To achieve these goals, we are introducing three separate channels to enable faster iterations while ensuring that final releases are stable and extensively tested.
Learn how to get access to the different channels in the docs.
The alpha channel is ideal for contributors and developers who want to try new features as early as possible. Features on the alpha channel are not fully tested and might see significant changes before they are included in a stable release.
Features on the beta channel are tested and unlikely to change before the final release. The beta channel is a great way to try new features and provide feedback before they are available in a stable release.
We recommend that you run the stable channel on your production servers. Releases on the stable channel follow a bi-weekly cadence and only include very minor changes compared to the beta channel. This ensures that the combination of features in a release has been thoroughly tested on the beta channel.
A new feature in Prisma starts its life as a feature request on Github. This chart describes the stages a feature goes through before being included in a stable release:
Scoping out a new feature is a collaborative process that takes place on GitHub. Many feature requests are driven by the community, but usually a core contributor will ensure the spec is complete before any development work is done.
During feature development, core contributors work on new features and merge community PRs. All work is done on separate feature branches. When a new feature is implemented, reviewed and tested in isolation, it gets merged to the alpha branch. At this point a new release is automatically published on the alpha channel.
Towards the end of the two week cycle the alpha channel enters feature freeze. During this period, extensive integration tests are performed and small fixes are merged to the alpha branch.
At the end of the two week cycle, the alpha branch is merged to the beta branch and a release is published to the beta channel. At this time the two week cycle repeats and normal feature development takes place on the alpha branch. The beta period lasts two weeks and no new features are added during this time. The beta period is a great way for the community to validate new features before they are included in a stable release.
At the end of the beta period, the latest beta release is promoted unchanged to a final release. At this point the beta branch is merged into the master branch. For the next two weeks no new features will be released on the stable channel - but we might issue a point release if a critical bug is discovered.
The following diagram illustrates how feature development and beta period of consecutive release cycles overlap:
With a structured release process in place, we now have a solid foundation for building and delivering many new Prisma features in the coming years. We just started following this new process and the
1.9 release (scheduled for June 5) will be the first to go through the entire release cycle.
The next two releases will be
1.10 which introduces many improvements to the Postgres connector, including support for existing databases with more complex schemas, and
1.11 introducing experimental support for MongoDB.
In the near future, we will publish a long-term roadmap laying out the direction for Prisma over the next 6-12 months.