Re: Time (to start planning) for a new release?

On Tue, 16 Jan 2024 at 15:49, Robert Eden <[email protected]> wrote:
>
> On 1/16/2024 2:20 AM, Geoff Westcott via xmltv-devel wrote:
> > We should probably tempo disable the GitHub 'Action' that builds the
> > Windows (and maybe the Linux?) releases while we are updating.
> > Reason = they pick up the "Release" tag from GH and so might overwrite the live 1.2.1 with changes-in-progress (and so the real 1.2.1 will be lost from history - q.v. https://sourceforge.net/projects/xmltv/files/ ).

Pre-release versions should be tagged with a corresponding pre-release
tag so that there is no confusion. The version string would make it
clear what the built package represents. Github also allows
pre-releases to be marked as such.

Nothing should be lost from history; once a new (pre-)release tag is
applied and pushed to Github, it should not be removed.

Whether Windows builds are disabled during pre-release testing is a
separate question. Build testing is usually a good idea.

> Is there a way to an "-interm" or something to the version field in the
> unreleased tags to separate it from actual releases?
>
> What about using the second number for official releases and the last
> number would signify the unofficial sequence (maybe not even update...
> just set to .0 on release then change to .1)

If we want to tag pre-release versions it makes sense to continue to
adopt SemVer [1] for the pre-release versioning. E.g. (assuming 1.3.0
is the next version):

1.3.0-beta.1
1.3.0-rc.1

  [1] https://semver.org/


Does this make sense?

Cheers,
Nick