Change log

[bquistorff]

It would be nice if we had a change log. See keep a changelog. They are helpful to both users and maintainers (helpful for history and for easily understanding changes by others). It would require a bit more work to (a) think about what are "releases" compared to just commits (SSC releases obviously qualify, but we'd likely include others as well), and (b) write up and summarize changes. Anyone have thoughts on this trade-off?

[gvegayon]

I like what these guys do https://github.com/RcppCore/RcppArmadillo

[gvegayon]

Actually, I've just added it https://github.com/gvegayon/parallel/blob/master/ChangeLog (follows this https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs) The idea is to record daily changes (if any) there.

Also I was thinking we could start renaming development version. In R the last digit is .9000 (or something like that). What do you think?

[bquistorff]

I thought R used Semantic versioning (from this doc)? What do you mean by the last digit being 9000?

[gvegayon]

I thought R used Semantic versioning (from this doc)?

That's a suggestion (which I'm thinking of including on my packages). I'm used to using dates, for me it's more clear as one can see right away how old/new it is. But that's me! Maybe we should change that in parallel?

What do you mean by the last digit being 9000?

I meant this http://r-pkgs.had.co.nz/release.html#release-version

[bquistorff]

Well, you just added the change log file (thanks!) so we can use that for dates/freshness, and do semantic versioning. With the existing scheme only the first part is non-date, so it's hard to tell about compatible vs incompatible changes (someone would have to look through the whole history of the changelog to figure that out).

I see what you mean by the .dev-part/9000. Sounds goods.

[gvegayon]

Current version is 1.16.4.30, so we should change it to 1.16.9000 and then next SSC version should be 1.17.0 (makes sense?)

[bquistorff]

Sounds good.