Giters

hashicorp / go-changelog

Changelog generation based on files in a directory.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hello :-)

fabianotessarolo opened this issue · comments

commented

Hi @paddycarver how are you? I was giving a look on your project and I have a need related to this, do you have anywhere plans for this project? Do you have plans to work towards https://keepachangelog.com/en/1.0.0/ also?

I would like to learn go, maybe I can help try with simple features from the backlog.

Thx.

commented

Hi @fabianotessarolo, we currently don't maintain a roadmap for this project, as we're still experimenting with our needs internally, and intend to evolve it to meet those needs as we discover them. This could mean drastic changes in design or direction.

What specifically about Keep A Changelog are you asking if we intend to work towards?

I appreciate the offer of help! One of our more mature and well-defined projects may be a better place to get started; I'd recommend the good-first-issue issues or the help-wanted issues in the hashicorp org, or the terraform-providers org.

commented

Hi @paddycarver , about the keep a change log, the doubt is it if you are planning to follow the recommendations of it on this project, or follow a different pattern.

Ah I see, oh okay, I will keep an eye on this project and contribute on other than.

Thx

commented

As best I know, here's our intentions around the recommendations on Keep A Changelog:

  • Changelogs are for humans, not machines: This is a central goal of this project
  • Entry for every version: yup
  • Group similar changes: we support this already
  • Linkable versions and sections: already supported
  • Latest version comes first: already supported
  • Each version has a release date: outside the scope of this project, should be included in your release script
  • Mention whether you follow semver: supported
  • We will not be using the types of changes that Keep A Changelog recommends, HashiCorp has its own style guide for those. The library supports any type of change, however, so consumers can still use the Keep a Changelog recommendations.
  • Keep an Unreleased section at top: supported
  • Avoiding everything in the "Can changelogs be bad?" section: supported
  • Standard changelog format: HashiCorp will continue using our standard format, this tool supports the standard recommended
  • Changelog naming: this project doesn't care what you name your changelog
  • Rewriting changelogs: this project supports it
  • Yanked releases: supported

I hope that answers your question! I couldn't find any other recommendations.

It looks like there isn't a unit of work to be done here, so I'm going to close this out, but please feel free to chime in if there's something I missed.