https://pantsbuild.org/ logo
#general
Title
# general
h

high-yak-85899

04/12/2022, 8:39 PM
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.
h

hundreds-father-404

04/12/2022, 8:40 PM
Nothing out of the box. I'd be curious to explore that though
h

high-yak-85899

04/12/2022, 8:41 PM
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.
👍 1
e

enough-analyst-54434

04/12/2022, 8:46 PM
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.
h

high-yak-85899

04/12/2022, 9:19 PM
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?
My guess would be to gather all the transitive dependencies of our targets of interest, then gather everything that has changed, and find the overlap of the set. Tough point about choosing what to use as the base, but I'll likely just do upstream branch for right now.
h

hundreds-father-404

04/12/2022, 9:35 PM
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
a

ambitious-actor-36781

04/12/2022, 10:28 PM
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'
📆 1
👍 2
only downside is you can't deploy code twice a day
h

hundreds-father-404

04/12/2022, 10:30 PM
could add hour heh
a

ambitious-actor-36781

04/12/2022, 10:31 PM
oh maybe thats what I did. Honestly I can't remember this was 6 months ago.
but whatever it was, the sentiment was the same. Fake semver. get monotonic versioning. No more "forgot to do a version change" bugs.
💯 1
h

high-yak-85899

04/12/2022, 10:35 PM
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.