Include optional footer for commit range

[JakeGinnivan]

I would like to have under the issues list something like this:

Commits: b0ef2eb...62e4c21

or Commits: [b0ef2eb...62e4c21](diffurl)

[nikmd23]

@JakeGinnivan do you think that commits would just be a rel as described in #7? Are you actually interested in the commit hashes, or just the URL?

[JakeGinnivan]

I am interested in the commit hashes for https://github.com/JakeGinnivan/GitReleaseNotes

It is useful for appending new items to the release notes

[laedit]

:+1: for this, the commit hashes could be recognize as footer.

[avanderhoorn]

Seems a reasonable request to me. Wondering if there are other sorts of metadata that would come out similar to this... just wondering if its worth considering them together?

As in, there is a formal concept of "footer metadata" which is made up of known key/value pairs like "Commits", "[b0ef2eb...62e4c21]|[[b0ef2eb...62e4c21](diffurl)]"

[laedit]

Great idea! I don't think of any other metadatas right now but supporting this allow us to add some later.

[avanderhoorn]

Thanks what I was thinking. Anyone else think of anything?

[JakeGinnivan]

Maybe download links to source/zip etc?

[laedit]

Something like this?

Source: [myApp-source.v0.1.0.zip](https://github.com/laedit/myApp/release/latest/source.zip)
Compiled: [myApp.v0.1.0.zip](https://github.com/laedit/myApp/release/latest/myApp.zip)

[laedit]

Additional thought, it can be handy to include the checksum of the files:

Source: [myApp-source.v0.1.0.zip](https://github.com/laedit/myApp/release/latest/source.zip) / checksum (md5): 99c3a849f6e9a0d143f057433c7f4d84
Compiled: [myApp.v0.1.0.zip](https://github.com/laedit/myApp/release/latest/myApp.zip) / checksum (sha-1): bf35fa420d3e0f669e27b337062bf19f510480d4

What do you think?

[JakeGinnivan]

Sounds good. The checksum should be optional. Is it just the keys we are enforcing right? Or do we enforce the structure?

[laedit]

Yes, checksum is optional. The keys are defined in order to distinguish the metadata from the summary, but I don't know if it's worth it to check the value/structure. I have made it in #19 with a simple regex in order to validate that the value contain two hashes, but for download I think it can be anything from a url to a link with any extension (or no extension at all), so for this one I think we can just accept any values after the source and compiler keys.

[JakeGinnivan]

Just thought of another, contributors which will list the people who contributed to each release

[laedit]

Something like this?

Contributors: Jake Ginnivan, Jérémie Bertrand

[JakeGinnivan]

Yep, I tend to do [Name](GithubProfileLink) so it's a markdown link

[laedit]

Yeah, I think this one should not have to be checked on the value side.

[JakeGinnivan]

Thinking through generating/updates existing release notes a generated at: <time> would also be very handy

So basically, I think we need

• Contributors
• Commits
• Source
• Binaries
• Generated at

I think that should do it for now :P

[laedit]

All right, another good thought. I'll update #19 when I'll have the time.

[avanderhoorn]

Do we think these metadata "titles"/keys need to be namespace? Like:

• Release\Contributors
• Release\Commits
• Release\Source
• Release\Binaries
• Release\Generated

[laedit]

Personally I don't see the point, the metada are linked to one release so I don't think it can be a problem. But I might missing something.

@JakeGinnivan concerning generated at:, we must agree on a universal date format, do the 'year-month-day` like for the release date in #11 is ok?

[JakeGinnivan]

Lets just follow http://en.wikipedia.org/wiki/ISO_8601

Should we use UTC so yyyy-mm-dd HH:mm:ssZ (Z for zero offset), or should we put the timezone which the release notes were generated in?

[laedit]

I have preference for UTC but since right now you are the only user of this metadata, what is the best for you? :smile:

[JakeGinnivan]

Don't really care. It is a tool which is going to use this to append new items to an existing release.

[laedit]

So let's say we use UTC.

[JakeGinnivan]

Yep :+1:

[avanderhoorn]

I'm good with that format and UTC sounds good. Regarding namespaces, guess I'm wanting to make sure that we don't shoot ourselves in the foot.