You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need up-to-date libraries that we build upon. For instance ical4j 4.x has bug fixes that we need and up-to-date timezones (outdated timezones create more and more problems, see #113).
What
Updating ical4j 3.x to 4.x is a huge change because a lot of calls change, also semantically.
Main change is that it now uses the Java 8 Time API (also for timezones). See the mapping.
According to the "always have a working main branch" principle: All sub-issues should be merged to the ical4j-3to4 branch because they will break compilation and tests. So we can work on that one until it's finished and working, and then merge that one into main (with rebase/merge, not squash).
However PRs must ensure that the tests of their domain succeed again. For instance, if a PR rewrites CalendarUidSplitter, then it must make sure that the tests regarding this class succeed after the PR.
When creating PRs, the "Create a branch" link in the Github issue could be useful. You can select the ical4j-3to4 branch as base branch there:
(For next time: Can we just create a ical4j-3to4/xxx branch manually? I like the slash to group everything around ical4j-3to4. However Github said it's not a valid branch name.).
Important
When creating a PR, make sure that it wants to merge into ical4j-3to4 and not into main!
Further hints
(We can add things here when we discuss how to proceed.)
Update helpers "on the go"? Will probably cause merge conflicts, which could be a chance to extract the best of both variants
Set up branch protection rules for this sprint?
Refactoring during PRs: yes / no / minor?
If it turns out that we forgot something (for instance a class/package) in the sub-issues, how/when to add it to the sprint?
Why
We need up-to-date libraries that we build upon. For instance ical4j 4.x has bug fixes that we need and up-to-date timezones (outdated timezones create more and more problems, see #113).
What
Updating ical4j 3.x to 4.x is a huge change because a lot of calls change, also semantically.
Main change is that it now uses the Java 8 Time API (also for timezones). See the mapping.
See also:
How not to break everything
According to the "always have a working main branch" principle: All sub-issues should be merged to the
ical4j-3to4branch because they will break compilation and tests. So we can work on that one until it's finished and working, and then merge that one into main (with rebase/merge, not squash).However PRs must ensure that the tests of their domain succeed again. For instance, if a PR rewrites
CalendarUidSplitter, then it must make sure that the tests regarding this class succeed after the PR.When creating PRs, the "Create a branch" link in the Github issue could be useful. You can select the
ical4j-3to4branch as base branch there:(For next time: Can we just create a
ical4j-3to4/xxxbranch manually? I like the slash to group everything aroundical4j-3to4. However Github said it's not a valid branch name.).Important
When creating a PR, make sure that it wants to merge into
ical4j-3to4and not into main!Further hints
(We can add things here when we discuss how to proceed.)
ICalendarGenerator/ICalendarParser#185 into one sub-issue/PR for the generator (+ tests) plus one sub-issue/PR for the parser (+ tests).