chasinglogic
year ranges
We have to maintain copyrights on files that include the first year the file was created, and then the most recent year it was changed (if different)
Which means we have files that have year sections that look like this: [name] 2000, 2023.
Is there a way for this project to place nice with existing headers?
There is definitely a way I'll spend some time investigating this this week to see what I can come up with for you
@hcldan I think the issue with this is that llcensure doesn't have a good way to know when the file was created.
I can think of some ways to beat this functionality into the code with regards to generating the year range string and getting the last updated date of a file is fairly trivial (assuming you'd trust git or file system metadata about such things).
I guess I could use git to get the date it was added.
Would using the first and last commit date of a file work for your use case?
@hcldan I've put up this PR: https://github.com/chasinglogic/licensure/pull/40
I've created a release candidate from that branch here: https://github.com/chasinglogic/licensure/releases/tag/0.5.0-rc2
Can you give it a test and make sure it meets your needs? The README has updated documentation on that branch you can view here:
https://github.com/chasinglogic/licensure/tree/0.5.0-rc2?tab=readme-ov-file#year-ranges
The TL;DR of that is add use_dynamic_year_ranges: true to your license configs.
I fully expect that it will duplicate your license headers when converting from non-range years to ranged. Which is a bug I encountered when testing but isn't one that I can find a real solution for that isn't extremely ugly and hard to maintain code. So I'm not sure I will support it and will just advise to clear out your headers before running it for realsies.
@chasinglogic My apologies, I've been trying to get to this, and work has had be very busy. I'm going to try to get to it this week.
I need to do a bit more testing. I updated my config to use both a start_year and the dynamic range.
I got an error for a rather new project saying i needed to update:
<!-- © Company 2024, 2024. All Rights Reserved. -->
<!-- © Company 2024. All Rights Reserved. -->
Hopefully that's an easy one to fix.
Actually I see that start year is unnecessary when using dynamic. Getting this info from git is perfect, would just want it to be a single value if they are both the same.
Ok that was pretty easy to implement but my belief is that if I make the year singular when the year updates it won't be smart enough to just update the header and will have the same double header problem it has for existing headers.
This is quite hard for me to test because I don't have a repository that I can run it on that has a good mixture. I've pushed that version up though so you can try it out.
I'll have to spend a lot more time finding a way to write unit tests for this and it will be complicated.
I take all that back, I figured out how to make it work and should be basically bug-free (including now migrating from non-year ranges to year ranges).
Excellent. Is there something else you'd like me to test? Is there a release with this planned soon?
@hcldan if you can test the release candidate and confirm it works I will do a proper release
@chasinglogic put a comment in the PR, but yes, I tested it with my projects and it looks good.