How to follow updates?

[willbush]

I love the project! I find myself coming back about every week to see what's new. Is there a better way? Perhaps a community were announcements are done? If not perhaps releasing a changelog and people can sign up to watch? Thanks!

[isabelroses]

Well hopefully #124, should save a bit of hassle when it comes to tracking, otherwise it might be cool to have a changelog.

[willbush]

You might consider @infinisil's approach he's been working on. NixOS/nixpkgs-check-by-name#38

[sgoudham]

Well hopefully #124, should save a bit of hassle when it comes to tracking, otherwise it might be cool to have a changelog.

This repository uses release-please but I don't believe a release has been cut yet for the changelog to exist. I'm not sure what @getchoo's plan is for v1 before merging #65 but I'd personally have probably merged v1 when it got transferred into the organisation

[getchoo]

I'm not sure what @getchoo's plan is for v1 before merging #65

in all honesty, i'm not sure either. this is an issue i've definitely put to the side over the last few months, as i feel most releases would be fairly arbitrary (with the exception of v1 when the transfer happened...that would've made a lot of sense lol) with the current pace of additions. i also think some aspects of semantic versioning like bumping the major version for public api changes could introduce problems at the scale of so many ports. a good example would be changes in individual ports possibly changing appearance; would that be a breaking change? what about any ports that may be dropped by the org for some reason? would each of those constitute api breakage and a major release?

a solution i've been considering both for solving the problems with versioning and (more on topic with this issue 😆) is possibly having snapshot/date based releases. i think this would be more representative of the project's rapid additions with few (if any) backwards incompatible changes, and give a way to consistently update people on these changes at regular intervals

curious to here what others think would be a good approach here, since i know versioning in nix can be a pretty controversial topic

[sgoudham]

curious to here what others think would be a good approach here, since i know versioning in nix can be a pretty controversial topic

Two things from me:

1. Ultimately, I don't mind what versioning scheme we use as long as we're consistent and stick to the rules that we end up defining. Regarding the existing semver versioning, I think it's a very slippery slope if you start to consider the actual changes to themes as breaking changes/features. I think the semver aspect should be purely contained to the actual repository (e.g. changing an existing option or removing an existing port would be a breaking change, adding new ports would be features, etc?)

   Datetime based releases seem like a good option if we decide that semver doesn't make enough sense here, but it's worth noting that we'd have to rip out the existing release-please config.

2. I'm not too involved in the nix ecosystem but my first thoughts are to look at prior art and see what versioning schemes other repositories similar to ours use?

[willbush]

Worth consideration:
https://lobste.rs/s/ynhu2s/effver_version_your_code_by_effort

https://jacobtomlinson.dev/effver/

[isabelroses]

1. Ultimately, I don't mind what versioning scheme we use as long as we're consistent and stick to the rules that we end up defining. Regarding the existing semver versioning, I think it's a very slippery slope if you start to consider the actual changes to themes as breaking changes/features. I think the semver aspect should be purely contained to the actual repository (e.g. changing an existing option or removing an existing port would be a breaking change, adding new ports would be features, etc?)
   Datetime based releases seem like a good option if we decide that semver doesn't make enough sense here, but it's worth noting that we'd have to rip out the existing release-please config.
2. I'm not too involved in the nix ecosystem but my first thoughts are to look at prior art and see what versioning schemes other repositories similar to ours use?

I don't particularly think this repo needs releases at all. Since people can pin this flake to a certain commit. But If we really did want releases we could use flakehub.

And in terms of things breaking on this repo, nix provides some nice lib functions for renaming modules and removed ones and so on.

[willbush]

#124 is good enough for me. Feel free to close the issue.

[Liassica]

A simple way to be notified of updates would be to follow the Atom feed for commtis to this repository, https://github.com/catppuccin/nix/commits/main.atom, though that of course wouldn't filter new additions from other types of commits.