Version 6 - roadmap

[niccokunzmann]

We would like to release version 6 soon. In this issue, I propose a plan and gather your ideas and requirements for what that big version change means.

What to include:

• [x] Create a last 5.x release before #623
• [x] Merge #623, finish #609
• [x] Create a 5.x branch
• [x] Go through all the issues and list those related and required here
• [x] https://github.com/collective/icalendar/pull/634
• [x] https://github.com/collective/icalendar/issues/627
• [x] drop the claim that we maintain 4.x
  • https://github.com/collective/icalendar/issues/459

  • 513

• [x] https://github.com/collective/icalendar/issues/424
• [x] #278 - easy
• [x] #67
• [x] Make sure people understand what changes: The functionality is extended!
• [x] https://github.com/collective/icalendar/issues/609

Related:

• 395

• 336

[niccokunzmann]

This is on the roadmap:

• [ ] generate a warning if pytz is installed and how to make icalendar use pytz.
  • in setup.py?
  • in icalendar.__init__?
  • not at all?
• [ ] Create a release alpha or stable?

@thet - How would you perceive a good transition process?

My bit:

With my libraries, I say: install icalendar with a fixed major version so that I can be sure that compatibility is there. I also increase the major version with any breaking change.

• [ ] We should document that one should install icalendar==6.* - https://github.com/collective/icalendar/pull/660

[stevepiercy]

I think we should use alphas for 6 now. That clearly communicates that (1) there are changes in the release that may not stable and feedback is desired, (2) makes it easier to install a specific alpha version, and (3) shows that there is release activity. There may be more good reasons.

I use zest.releaser for releasing. The maintainer is the release manager of Plone. It's well designed, and catches things that I might miss.

[niccokunzmann]

I use zest.releaser for releasing. The maintainer is the release manager of Plone. It's well designed, and catches things that I might miss.

I had a look at the documentation and I do not know how it works. I think, I could open an issue or contribute documentation. The manual way that is described here: https://icalendar.readthedocs.io/en/latest/maintenance.html also means that if I die, people can just follow it and know what to look out for.

Thanks for the suggestion though... I should try it. I will wait a bit longer for @thet to give some input and #660 to be merged.

[stevepiercy]

Yeah, usage is buried under available commands: https://zestreleaser.readthedocs.io/en/latest/overview.html#available-commands.

It would be good to show the interface in the usage documentation instead of a wall of text. It essentially asks a series of questions, providing sensible defaults that you can accept or edit such as [Y/n] or 0.0.8, and holding your hand through the release process.

[niccokunzmann]

I am working on creating an alpha release.

https://packaging.python.org/en/latest/specifications/version-specifiers/#public-version-identifiers

v6.0.0a0

[niccokunzmann]

It is official, we can install this alpha release from pypi.

pip install icalendar==6.0.0a0

[niccokunzmann]

Should we document this... I think so...

[niccokunzmann]

Announcement made: https://github.com/collective/icalendar/discussions/687