Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: switch to fixed versioning #776

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mihkeleidast
Copy link
Member

Filing this as draft but I would like to make this switch at some point in the near future. We opted for independent versioning at the start so importing existing packages would be easier. In the long term, in my opinion, independent versioning does not work very well with conventional commits. One issue is that when adding new packages at 0.x they never get automatically bumbed to 1.x with conventional commits - they should be bumped manually, but who can determine when te correct time is 馃し . For example, look at the versions of our core/web packages :)

Additionally, fixed versioning should work better with communicating what versions of different packages work together. Right now, we have some cases in docs where we need to specify "needs fractal X and mandelbrot Y" (for example, the root collections option), because the packages are bumped independently. With fixed versioning, we could always say that "use version X of both or latest".

Notes on merging/releasing this:

  • currently I've marked the version in lerna.json to be the version of the package with the current highest version (nunjucks). It should be bumped here if new releases are made before merging this.
  • before this is released, the last release commit should be tagged with a "normal" npm tag in the format of v1.2.3. That should inform lerna/conventional commits that that's the correct release to bump from.
  • it's probably a good idea to do the release manually, since I've only ever done a switch like this once before and all I can remember from it is that it's a hassle 馃槵 . Can't be sure that adding the tag I mentioned in the previous point resolves all issues, so better to do it manually.
  • oh, and we can probably discuss what the next version should be - we could probably get away with doing a major bump here as well. Did we have some issue with releasing v2 or v3 and should the next major be v4? Additionally, are there any small pieces of legacy code that would be easy to remove? We could also do that before bumping everything to the same version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant