Released a stable version

[tkna91]

I am requesting a CDP package below, but it would be preferable to have a stable release.
osam-cologne/archlinux-proaudio#305

Sorry to bother you, but I would appreciate it if you could tag the release.
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

[tkna91]

If you have any suggestions on package name and description, please let me know.

[SpotlightKid]

A tag in the Git repo at the point Release 8.0 was made would suffice, but creating a GitHub release from the tag would be even better.

The reason is that for packaging, as a general rule, we'd like to build from a source distribution archive, which:

• is built from a specific commit/tag of the source repo.
• does not change after the release and this can be checked by a checksum.
• includes the version number in its filename (so that the next release does not use the same file name).

This is all in the interest of reproducibility and longevity (i.e. also package of previous versions can still be built in the future).

[jpffitch]

I agree. Surely we should make use of github release mechanism

…

-------- Original Message -------- From: Christopher Arndt ***@***.***> Sent: Fri Nov 17 23:55:50 GMT 2023 To: ComposersDesktop/CDP8 ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [ComposersDesktop/CDP8] Released a stable version (Issue #4) A tag in the Git repo at the point Release 8.0 was made would suffice, but creating a GitHub release from the tag would be even better. The reason is that for packaging, as a general rule, we'd like to build from a source distribution archive, which: - is built from a specific commit/tag of the source repo. - does not change after the release and this can be checked by a checksum. - includes the version number in its filename (so that the next release does not use the same file name). This is all in the interest of reproducibility and longevity (i.e. also package of previous versions can still be built in the future).

-- Reply to this email directly or view it on GitHub: #4 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[jpffitch]

I think I have created a source release. New to this aspect of github

[SpotlightKid]

So version 8.0 is the same as 8.0.1?

[richarddobson]

If that is with reference to the README file, I am happy to edit that to make it 8.0. Individual programs have a wide range of version numbers (used by SoundLoom in various mostly hidden ways, to discover which versions of various CDP programs are installed), including a few up to 8.0.1. Some are still at 7.0.0 (etc, and even earlier) as they are unchanged. RD.

…

On 18/11/2023 15:15, Christopher Arndt wrote: So version 8.0 is the same as 8.0.1? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4WR6FFSRRWOYNIEPY3YFDGHNAVCNFSM6AAAAAA7QP4VPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGUZTINZYHE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SpotlightKid]

The README says "Version 8.0.1 (Beta)" and the download page, linked from website, says:

CDP has now released its 8th software upgrade (the first since 2014).
Release 8.0 (Oct. 2023) strengthens CDP's toolset [...]

Versions of included components do not really matter in this context. The goal is to have an identifiable state of the code (i.e. marked by a unique version number that refers to a specific point (tag) in the git history), that can be also be retrieved later with the certainty that later changes do not affect this versions (i.e. by a source distribution archive with a unique file name).