Victory is turning 30!
Victory is making the change to major versions with the release of
This is an unusual version bump, and a major milestone for the project, so we thought it warranted more explanation than we usually provide in our release notes.
What's happening in this version?
The biggest change in
firstname.lastname@example.org is the transition from multi-repo to monorepo development. After this change, all
victory-* packages (with the exception of
victory-native) will be developed and released from a single github repository: .
Why a monorepo?
Our number one reason for transitioning to a monorepo infrastructure was to improve developer workflow and make it easier for people to contribute to Victory. Before this change, we were using , , and some to share infrastructure across several github repos. This meant that would-be contributors needed to clone and link several repositories to get started on the project. For maintainers, this meant keeping track of multiple, related pull requests, and carefully coordinating interdependent releases. Transitioning to a monorepo eliminates most of this friction, and comes with several additional benefits:
Easier to understand infrastructure: Lerna is much more commonly used than Builder, so it's much easier for contributors to find resources to help them get started.
Easier to change and update infrastructure: With Builder, most code infrastructure was extracted into a separate archetype package, which added friction to infrastructure changes.
Easier to modularize: Because Lerna automates most of the work of updating and publishing packages, it became feasible to break Victory into smaller packages. With our transition to a monorepo, we've increased the number of dependent
victory-*packages from 3 to 25.
- Better for open source: Issues, pull requests and code together at last!
Why Version 30.0.0?
Victory is jumping from pre-1.0.0 to 30.0.0. Why are we skipping all those versions? Our massive version leap is mostly due to our transition to a Lerna monorepo. We decided to use lock-step versions for all of our dependent packages to eliminate potential confusion and version mismatch. In order to give all packages the same version number, we needed to choose a version number higher than the highest version of our existing packages.
victory-chart was version 27.1.1 prior to this change. We decided to round up.
What does this mean for users?
Users who are consuming Victory components directly from packages like
victory-core should be aware that components have likely moved to new packages. The complete list of components that have moved can be found in our .
What can users expect in the future?
Victory users can continue to expect frequent releases and up-to-date changelogs. Victory will use standard , with all packages kept in version lock-step. We also hope these changes will help to accelerate Victory's release cycle and encourage more community contribution.