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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Bump dev version #778

Closed
wants to merge 1 commit into from
Closed

Bump dev version #778

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ build-backend = "hatchling.build"

[project]
name = "metricflow"
version = "0.202.0"
version = "0.202.0.dev4"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
version = "0.202.0.dev4"
version = "0.203.0.dev1"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that was not my understanding of how we move to dev versions. I was confused to see we had moved from 0.202.0.dev3 to 0.202.0, because it seems like a reversion? Is that how we've always done it and I'm just being crazy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, don't we start with dev0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just went to check commit history and at least in recent bumps (excluding the last one you bumped to 0.202.0) we have been following the pattern of 0.200.0 -> 0.200.0.dev0 -> 0.201.0. There seems have been some fluctuation over time about what pattern we use.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, yes, it should be 0.203.0.dev0 although I'm not too concerned with the dev version value itself, as long as nobody ever goes backwards.

We've actually always followed the <existing release version> -> <new version with pre-release> -> <new version> standard. We moved from 0.140.0 to the 0.200.0.dev0 pre-release and then moved from the 0.200.0 pre-release to 0.200.0

Among the confusing things in our history we have:

  1. Devon's PR for the 0.202.0.dev0 pre-release has the wrong title, which I'll fix, although the git commit history might just be busted and I don't want to rewrite it just for this
  2. There was no pre-release for 0.201.0 - that was a straight release of the new version.

All of this confusion (and you're not the only one, it happened to Devon and to tell you the truth I need to look it up every time myself) tells me I need to move our version updating to be something scriptable, add that to the goofy shell script I wrote for making release PRs, and maybe put that up for review so all of us can use it for at least these mechanical dev version PRs.

description = "Translates a simple metric definition into reusable SQL and executes it against the SQL engine of your choice."
readme = "README.md"
requires-python = ">=3.8,<3.12"
Expand Down
Loading