UK change to 2020 early May bank holiday about calendra HOT 11 CLOSED

Hi Shaheed. Thanks for the info.

Besides your reported concern, there are two additional concerns at play here:

• I don't have much time to spend on this project, so I'll only occasionally have time to keep the codebase in sync with the upstream changes. I won't be able to contribute new functionality or changes, but I am happy to review pull requests and cut releases.
• This issue probably should be first fixed upstream in the workalendar project. This fork seeks mainly to address the shortcomings of that project. This concern is exacerbated by the prior concern :/

from calendra.

I was not previously clear on the relationship to upstream, but I now see a report there is the right first step. Thanks!

from calendra.

Added upstream issue as suggested.

from calendra.

FYI, upstream has released a fix for this. Will you be able to do the sync or should I attempt one and do a PR? There is no immediate urgency pushing this, and a few weeks here or there would not be an issue for me if that helps.

from calendra.

I'd be delighted if you would put together a PR, but I'd like it to include a merge of the master (or tagged release) following the patterns from previous syncs... which means you may run into conflicts and you may not be aware of the best resolution for those conflicts. Still, I'll have limited time to support this project, so to the extent that you can help support it, that would be most appreciated and I'm willing to spend whatever time it takes to help you with the process. Don't hesitate to let me know if you get stuck. Also, feel free (but not obliged) to document the process if it's not already (I don't think it is).

from calendra.

OK. Here is what I see so far, please add/correct as needed:

1. On 5-Jan-2019, starting with a6bbc34, you merged workalendar v2.6.0 and workalendar/3.2.1.
2. Later that day, you tagged "3.0".

Now, upstream has changed quite a lot between v2.6.0 and v5.2.2 (the latest). Many of the changes are simple mechanical changes (e.g. code re-orgs) which can be applied easily, but there are also a lot of actual content changes. So, I roughly speaking, I need to:

1. Find the diffs between upstream v2.6.0 and v5.2.2.
2. Strip out the diffs for files we don't want to merge (largely, this is the files in the top level directory).
3. The remaining diffs are for files in directory "workalendar" in upstream, and "calendra" locally.
   • Apply the mechanical changes en-masse.
   • Apply the content changes with due care.
   • It is not yet clear to me how much of this can be done using git merge versus careful patching.
4. Carefully record the tag to which we have synced, using git merge -s ours. This should simplify future resyncs.

Does that sound right? What have I missed?

from calendra.

Thanks for doing that analysis.

Find the diffs between upstream v2.6.0 and v5.2.2.

Actually, as you observed, the 3.0 release of calendra includes changes from workalendar up through 3.2.1, so you only need to consider the changes from v3.2.1 to v5.2.2.

It is not yet clear to me how much of this can be done using git merge versus careful patching.

I've always used (and recommend) git merge, so I don't omit any diffs and the full ancestry of every change is present. Git has been following the ancestry as well so is aware of the file renames (so changes in workalendar/ get mapped to calendra/ automatically).

But as you say, quite a lot has changed. One way I've found to manage the changes is to bite off in smaller chunks. For example, instead of merging v5.2.2, just merge for example v4.0.0, resolve any conflicts, verify tests run, and commit. Then repeat with another modest change until eventually you've merged v5.2.2.

At each merge, if the upstream has introduced any files that need not be included with calendra, then you should git delete them, but I'd only recommend that if the files are interfering with the package.

Note - you will get merge conflicts for the changelog. You'll want to reformat the changes following the previous pattern, so that changes from upstream are indicated as such.

Feel free to give a git merge d8be9de2aed8eed7e07d6e2a20f0fa511574f981 (workalendar/v4.0.0) a try and let me know how that goes.

from calendra.

Thanks for the feedback. I considered the step-by-step approach, but in the end there was little to choose between it and just going all the way!

from calendra.

A good way to ensure that know what changes to retain is use GitHub to look at the (presumed) intended differences were at the last merge. Here are the differences after merging workalendar 3.2.1.

from calendra.

This issue is addressed with the latest merge. Big thanks for your patience on this matter. I hope the delayed experience hasn't sullied your interest in the project. I'd be delighted if you'd like to take a look at another sync with workalendar, if you're up for it. No obligation, though.

from calendra.

from calendra.