Does pants provide anything out of the box for knowing if something like a version number for a python distribution, docker image, and other artifacts needs to be bumped? In our monorepo, someone might change something in a shared library and not realize that they should have bumped version numbers for the dependent packages.

Nothing out of the box. I'd be curious to explore that though

I think that's the main thing holding us back from semantically versioning some of our things (and instead going directly to something like a commit hash) because it's a bit easy to not realize you need to change things.

Pants v1 did this for jvm artifacts, but it was dumb. The

./pants publish ...

goal would just noop for any distribution that had not changed since last publish (content hash based) and it would bump the patch version by default if it had changed. No SEMVER smarts. You were presented with a diff though since the last publish which you could read to maybe remind yourself if you should ctrl-c out and add flags to the pulish goal to set a minor or major version.

Any recommendations on pants queries as a short term remedy? Thinking some kind of shell script like

check_versions.sh

that will tell locally if the targets we care about might be out of date?

Yes, I think that approach sounds right. Use transitive dependencies on your package targets. Then combine it with

--changed-since=

and

list

to see if there is any crossover, like diff the sets

I just went with

version: date.today().strftime('%Y.%M.%D')

because semver is a total waste of unless you're actually providing an external contract with an expectation of backwards compatibility and support and your consumers are able to use it. Which 99% of the time, I'm guessing is 'they are not'

could add hour heh

oh maybe thats what I did. Honestly I can't remember this was 6 months ago.

Yeah, I go both ways. I don't think we're going to use semver in it's most authentic form so there's rationale to drop. On the other hand, I don't like instructing people to specify the repo hash of our services that they want since that could either mean no change or a fundamentally different architecture.