year range about update-copyright HOT 6 OPEN

In anyway i just started to not putting a year in the file banners - don't know if this is a good thing or not.

Idk, I just want to be as compliant as possible so that companies and users who are required to follow rigid guidelines will be able to use our code without any worries.

from update-copyright.

What if we add an option to fill in additional years? Then, in the update updater, we can actually parse the years from the git history and provide those on the options...

I think this is a good idea.

from update-copyright.

k thx for the feedback @doowb and @tunnckoCore!

from update-copyright.

sadly even don't use update et al.

btw, I'm going to be pushing up changes that make update easier to override and customize. maybe that will help.

Even though you're not using update, I could use your feedback. Should we use ~/.update/ as the default directory for storing custom, user-defined config values for update (as well as any updaters)?

from update-copyright.

Side note: sadly even don't use update et al.

Don't know. I don't understand copyrights fully. I understand that if it is a range you hold the license for exactly that range of years, no matter modifications are made or not. I believe there should be a difference between 2014-2017 and 2014, 2017 - in the first case is that you hold the license for all the years in range, in the second case you hold only for 2014 and 2017, that's how i understand it.

Don't know, maybe if you can share some links to learn more. :) In anyway i just started to not putting a year in the file banners - don't know if this is a good thing or not. The only places where some years is set is in the readme, by verb.

from update-copyright.

Maybe yea. It would be good, I like hidden dirs :D

btw, I'm going to be pushing up changes that make update easier to override and customize. maybe that will help.

As about that... I just don't have the time to make updaters for me and my cases/templates.

from update-copyright.