Using tag prefix’s in a monorepo

[sheldonhull]

Is it possible to use components to generate unique component tags that version independently in each directory? I have 5-6 projects in a directory. I want to use changie to version but each project in the repo should be setting a prefixed tag output so I can move those independently.

The version tag should increment for each independently.
A tool I used in the past was svu that supported this.

I didn’t see any support for pulling the specific semver using something like changie latest —component ui would result in ui/v1.0.2.

[miniscruff]

Components are simply a header in a version, so there would be no way to separate them from the versions they are nested in. Changie latest works by searching the changes directory, so for anything like what you are suggesting to work it would need to either look in a specific directory or some how filter files.

Is your goal to make one shared changelog for all directories? Do you have any example repos or maybe a layout I can review? I have not thought much about how to use changie in monorepos where the directories are versioned separately.

One issue might be that prefixed tags are not proper semver and so there might be issues there.

[miniscruff]

Fair, it would need manual edits to at least a few files but I think it's mostly just moving them around. I could write up a guide for the steps of moving from N to 1 config and changes directory. The goal is that the output is the same just in different places without the need for anyone to cd to manage fragments or releases.

[miniscruff]

I think it would be best to develop and release this feature in a preview mode until any issues can be worked out, I have not done that for Changie before as all new features have always required a config change anyway. I do want to make sure the config changes and flow work well and feel good which I will have a hard time testing myself.

A base idea I have for that is simply displaying a warning prompt when using changie new and changie batch if projects are configured that they are in "preview mode" and mention that in the release notes until it is stable and good to go.

Other then that, its just a timing thing to get the work done.

[marcosnils]

I think it would be best to develop and release this feature in a preview mode until any issues can be worked out, I have not done that for Changie before as all new features have always required a config change anyway. I do want to make sure the config changes and flow work well and feel good which I will have a hard time testing myself.

Yep, sounds like a good plan.

A base idea I have for that is simply displaying a warning prompt when using changie new and changie batch if projects are configured that they are in "preview mode" and mention that in the release notes until it is stable and good to go.

Also SGTM!

[miniscruff]

Created an issue from my design above, no ETA on timing but it is at least visible in an issue.
#512

Edit: Release in v1.13.0 https://github.com/miniscruff/changie/releases/tag/v1.13.0

[gerhard]

We were talking about this today with @grouville (same context as @marcosnils - #506 (comment)) and either solution seems simple enough to me:

1. Add the change as a single command, e.g. changie new --kind "Fixed" --body "Show when Engine is loading in the output" --custom "Author=TomChv" --custom "PR=5488", then re-run the command in all directories that need it 💡 FWIW, I am a big fan of fc.
2. Create the change once, then just cp the resulting YAML file in all directories that need it, e.g. cp {,sdk/go/}.changes/unreleased/Fixed-20230715-131052.yaml

WDYT @marcosnils, would either of the above be enough in a monorepo?

[marcosnils]

WDYT @marcosnils, would either of the above be enough in a monorepo?

Yes, IMO either is enough given the current state of changie. Having said that, what I'd really like is if this "projects" idea move forwards is to add --projects to changie new and let changie handle the it internally 🙏

[sheldonhull]

Implementation so far seems great!

Here's some feedback @miniscruff.

• If changie new is changie and a project is required, make it a selector.
• changie latest --project myproject --remove-prefix removes the v prefix. If I get the latest version for a project I'd actually expect the semver version without the project name. Not sure best way to do this, if --remove-project from the version makes sense or if the default behavior would be to remove the prefix. That's sort of what I'd expect.
• I think to do tagging I need changie changesdir --project myproject to return the location of the pending changes. I use git tag -a "$(changie latest --project 'myproj')" -F ".changes/$(changie latest --project 'myproj').md" and now if I move or rename things would break.
• Idea: I have to script around the tagging, so having the equivalent of changie tag --project myproj and having a new git tag added with the message being the changelog file like my snippet would be a big help. I can keep scripting that, but since it's a versioning tool having it handle the tag addition and check for it existing would cut out more boilerplate. (For another example of this see SVU tool https://github.com/caarlos0/svu which I've used successfully in the past).

[sheldonhull]

Selector… when you pick components in changie new you can select from list when entering changie new.

I’d like the user to not have to remember the key in a repo and be able to select.

good responses! Cheers

[miniscruff]

Oh yea, project is the first prompt required if they are enabled.

[sheldonhull]

Ok so if I had project enabled and did changie new and it errored since I didn’t provide project that’s a bug?

[miniscruff]

Uhh yea that sounds bad lol. Please do post that. These are the concerns I had and why I marked it as a preview.

[sheldonhull]

Non-issue. I needed to run aqua generate -i miniscruff/changie to bump to version 1.13. For some reason maybe I was still running one edition prior.