Merge lp://qastaging/~allenap/bzr-update-copyright/force-ranges into lp://qastaging/bzr-update-copyright

Since I don't see a bug number that this is solving, a little background would be useful to help me understand. You mention "MAAS" as formatting years in the copyright statement either as a range or a single year. What is "MAAS"?

My second question regarding copyright dates is, "What is 'proper' and how hard would that be to implement?"

> Since I don't see a bug number that this is solving, a little
> background would be useful to help me understand. You mention "MAAS"
> as formatting years in the copyright statement either as a range or a
> single year. What is "MAAS"?

MAAS is https://launchpad.net/maas. We have a standard copyright header
at the top of each file. Naturally it begins life with a single year,
but that can later be substituted with a date range, "2012-2015" or
"2012, 2013" for example, without causing the line to extend to more
than 80 characters.

When there are three years and they're not all contiguous with one
another, bzr-update-copyright will render it longer, as "2012, 2013,
2015" for example. For us it means that the line grows long enough that
our linter complains, meaning we would have to reflow the header.

It sounds really lazy to have an issue with that, and I kind of agree,
but then I also don't want to replace one manual job (changing the
header dates) with another (reflowing the paragraph), especially when
forgetting to do the latter would cause our landing bot to reject
submissions.

In any case, we've always used ${year-created}-${year-last-modified} in
MAAS, albeit manually. We would be happy to condense the non-contiguous
example from earlier into "2012-2015", even though no changes were made
in 2014.

So, this isn't in response to a bug, it's an itch that I scratched.

> My second question regarding copyright dates is, "What is 'proper' and
> how hard would that be to implement?"

"Proper" may have been an overstatement. I think of the current
behaviour of this plugin as "proper", and --force-range as somewhat
"improper", but I don't actually know which is more proper than the
other. I was motivated only to automate our current practice without
disrupting existing users of bzr-update-copyright.

Thanks for the background.

I have a question regarding line 32 of __init__.py: Why is this the only line of option description text delimited by double quotes(")? All the others seems to use single quotes(').

Other than that, it looks good to me.

Thanks Richard. I've fixed the quotes to be consistent.

Thank you for the PEP8 clean up and the new option and documentation.
+1