How could pre-release tags be used when releasing without causing versioning issues?

[sheldonhull]

See image... How would you handle being able to only increment your release version on production releases, when the actual artifact being released has already been built and tagged? With changie you are basing your changes on files, and this could be different than when an image is built.

I work on trunk based releases.
I don't think that even using release branches would work as at the end trunk still needs the changie files for correct file calculations.

The only solution I can see right now is to increment on any release to a development environment, and not be able to batch the "prod release" version if the prod release version isn't actually rebuilding the artifact.

If this doesn't make sense, let me know and I'll try and rephrase all this. It's late :-)

[miniscruff]

Here is what I plan to implement at my work for our services. Our plan is to use a variant of https://miniscruff.github.io/hashver/ a semver compatible scheme that works better, imo of course, for live constantly updating services where compatibility is not a requirement.

The basic idea is, every commit to main pushes a new build to dev with a snapshot version. Something like vAPIVERSION.YYMMDD.HHMMSS+git-hash. Then, when we decide we have enough stuff ready to go, we do a PR/can just be a direct push to main of changie batch $(hashver stuff) && changie merge. By making a change to the changelog this goes to stage. This is us saying, our work is probably good and we are open to other teams calling our staging environment and our logs should be checked sort of thing.

Then when its time to merge to production, we just bump whatever the latest stage build is, this matches your diagram.

[sheldonhull]

Just saw this must have missed the notification. Gonna look through it. Thanks for the detailed answer.

[sheldonhull]

Ok. In your scenario the snapshot version image has been built. On running batch and merge you are essentially creating a new commit to save those files. That file change doesn't line up with the commit sha of the built image container.

If you could enforce a linear flow that you can never release a version that has changie fragments or version files that are different then I guess that might work though still is confusing.

If you can enforce a purely linear release the diagram works. If you have to release something that was built yesterday though and you know have other pending changes you are stacking those on the head of main, You'd run into the same situation.

Because a release is built from an artifact and promoted (container or binary) NOT rebuilt on changies action I can't think of the clean way around this. Most tools don't run into this because tags are pointers not actual commits to impact the trunk. If I was using changie an action to always build and release wouldn't be as confusing but an artifact being promoted and immutable means this diagramed workflow doesn't make sense for that.

I'm feeling I'll have to make some compromise here but haven't decided yet what that is. Any other ideas.
Nice diagram btw. Fellow excalidraw user? :-)

[miniscruff]

Yea all your points are accurate. I know rebuilding after a few metadata file changes are not great, I generally don't find it too bad as we are rebuilding between dev and stage, and build accuracy is insanely high.

Additionally, we are building many services and need to kinda release them all together, but its not perfect and we have had issues with db migrations and the linear flow. But, we don't even use changie yet so its not really Changie itself. We need to do this step as we deploy dev from a develop branch and stage from the main branch, so we need a PR regardless.

I am still considering steps to mitigate at least some of the steps, such as always batch+merging on every PR to our services ( libraries are fine ) if we want to release, but still have the option to build up a few changes into one release if we need to.

Kinda want to leave this open and come back to it when I have more concrete experience with live services.