Create changelog entry generators for common use cases #159

Activity

1. emmatown commented on Sep 17, 2019

   

   emmatown

   on Sep 17, 2019

   MemberAuthor

   More actions

   Important question: what naming convention should we use? @changesets/github-changelogs? @changesets/changelog-github? Do we care about having a naming convention for non-changesets scoped changelog entry generators?
2. Noviny commented on Sep 18, 2019

   

   Noviny

   on Sep 18, 2019

   Contributor

   More actions

   Blat of random thoughts:

   I vote @changesets/changelog-github for ones we publish but also I don't think trying to enforce anything strong here is important.

   The BB one can probably just be a standardising of the Atlaskit one.

   Do we want to do anything with the format of these files before doing this? For example making a single getChangelogEntry function rather than the currently awkward line-by-line option?

   Already written, but the 'basic' ones that come with the CLI is the other option (no git, no extras)

   I'd probably split `github into:

   • github
   • git (uses the git hashes, but doesn't fetch out
3. Noviny commented on Sep 18, 2019

   

   Noviny

   on Sep 18, 2019

   Contributor

   More actions

   git (uses the git hashes, but doesn't fetch out

   I'd like this to also not be the default, so apply-release-plan can stop supplying the hashes, but do worry about over-complicating these functions if we make function authors get that info.
4. emmatown commented on Sep 18, 2019

   

   emmatown

   on Sep 18, 2019

   MemberAuthor

   More actions

   I vote @changesets/changelog-github for ones we publish but also I don't think trying to enforce anything strong here is important.

   The BB one can probably just be a standardising of the Atlaskit one.

   Both SGTM

   Do we want to do anything with the format of these files before doing this? For example making a single getChangelogEntry function rather than the currently awkward line-by-line option?

   I'm think this is probably a later thing, mainly because I don't think we really have a big need for it

   github
   git (uses the git hashes, but doesn't fetch out)

   I'd like this to also not be the default, so apply-release-plan can stop supplying the hashes, but do worry about over-complicating these functions if we make function authors get that info.

   SGTM

   ---

   My general thoughts on most of these things is: Let's get the ideal behavior for most consumers and once we have the behavior we want, let's find the right internals/parts of the API that people use less.
5. Noviny commented on Sep 18, 2019

   

   Noviny

   on Sep 18, 2019

   Contributor

   More actions

   I'm think this is probably a later thing

   Fair. I know KS asked about more control here at one point and were disappointed they couldn't control the full thing.

   ---

   Let's get the ideal behavior for most consumers and once we have the behavior we want, let's find the right internals/parts of the API that people use less

   SGTM - action plan is go.
6. Noviny commented on Oct 25, 2019

   

   Noviny

   on Oct 25, 2019

   Contributor

   More actions

   This is done sans BB one right? That is probably a task for ATL people to resolve
7. emmatown commented on Oct 25, 2019

   

   emmatown

   on Oct 25, 2019

   MemberAuthor

   More actions

   Yes
8. Noviny

   closed this as completedon Oct 25, 2019