Create 6.x branch

[stevepiercy]

With the approaching release of 7.0.0, we should cut a branch 6.x from the last 6.3.1 tag.

This will allow us to:

• continue to develop 7.0.0 in alphas, betas, and release candidates on main
• let people test those versions
• backport bug fixes to the 6.x branch
• view docs on main as "under development", similar to what PyData Theme does https://pydata-sphinx-theme.readthedocs.io/en/latest/index.html

Ultimately this is a maintainer decision.

Meanwhile, I configured RTD to build main. Instead of trying to find the PR that has the new docs layout, you can now go to https://icalendar.readthedocs.io/en/main/

[niccokunzmann]

There is also latest which should be the same as the default branch which is then main.

The config at the moment builds and keeps the docs for all tags, too. stable is the latest tag.

---

I cannot remember getting any backport fixes since version 4. Our incompatibility with v7 is also pretty low, so it should work out that nobody is bothered about backporting. If they are, we can create a branch from the last version they want it in and work from there. My decision on this is: We do not worry about backporting fixes. We did worry with version 4 and nobody was interested. We can save some time and also focus on getting this package nicer.

Here, you can see the update status: #782

---

What are your closing criteria for this issue?

[stevepiercy]

stable is the latest tag.

This is why using "latest" for "development" is confusing, but we're stuck with it, unless we want to rename main to development (big nope!) or use tags (also nope!).

I dropped main from the builds. I didn't realize we had latest for the development, or main, branch.

TODOs

• On the main branch, add a warning banner to the docs that informs the reader to go to the stable branch.
• Cut a 6.x branch from the 6.3.1 tag.
• Remove 6.3.0 from RTD. We should only show the most recent version of each major release.
• Decide which major versions of icalendar to build with PyData Sphinx Theme and use its switcher. I can try each of 6, 5, and 4. Use warning banners on 4 and 5 versions.
• Start cutting alpha releases for 7, if you want to go through a more formal release process.
• Branch protection rules #976

Let me know what you think.

[niccokunzmann]

Your TODOs sound good! We can draft an alpha release. @SashankBhamidi - if you like to, you can draft the release, too. I just need to approve it, then :)

[SashankBhamidi]

Your TODOs sound good! We can draft an alpha release. @SashankBhamidi - if you like to, you can draft the release, too. I just need to approve it, then :)

Really?! Gladly! What version are we thinking? When do you want me to do it?

[stevepiercy]

@SashankBhamidi we follow SemVer. I'd go with an alpha.

[niccokunzmann]

What version are we thinking?

we follow SemVer. I'd go with an alpha.

Yes, that would be v7.0.0a
Linking: #932

[stevepiercy]

The example format in item 9 is 7.0.0-alpha.1. Python example 3.15.0a1. Either is correct.

I'd always use a number after the alpha designation, else alpha.2 or a2 feels out of place, in case you have another alpha. I also prefer - and . as separators because it makes it easier to parse. Also I prefer spelling out alpha and beta to disambiguate the meaning of a and b. These are minor details, whereas the most important one is to be consistent.

[stevepiercy]

For the sake of consistency with Plone releases, I'd follow their scheme and use 7.0.0a1.