Does pants provide anything out of the box for kno...
# general
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.
👍 1
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
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.
Yes, I think that approach sounds right. Use transitive dependencies on your package targets. Then combine it with
to see if there is any crossover, like diff the sets
I just went with
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
could add hour heh
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
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.