I am using Open API 3.0 specification to document my APIs.
I have observed that Open API 3.0 has a version attribute. I was wondering if it had a way to document changelogs. Or do just use the externalDocs attribute ?
Changelogs are not a built in feature of the specification but the version field definitely helps as the basis for generating them. I've got a GitHub action that does a "release" on GitHub when a specification version number changes (which is does for every change we make) so the releases page becomes our changelog. The data can also be taken from the releases (available via GitHub API).
As for pointing to a changelog - externalDocs is probably a good way to do it.
Related
GitHub has a public api that one can access to get current release info, and find the release file (.deb or .tar.gz or .exe, etc) by going to https://api.github.com/repos/[project creator]/[project]/releases/latest
Does GitLab have something similar? I'm working on an automated installer to get certain programs from GitLab that have releases. Using the above api for GitHub, I'm able to get the json info for the current release, and get the url to download the latest release, based on what version I want.
I'm hoping to find something similar in GitLab.
Look no further than GitLab's Release API Docs to start that investigation. It looks quite robust, and I believe you will find it can provide that information.
You can use this API to query for each project, looking for the releases it has. (You could also look for the availability of the project if you are unsure if it is present). Once found, determine the release to retrieve. It's important to note that releases are not always made by a team, so they hopefully are specifically packaging the code into a release for distribution. Additionally, via the API, you can also ensure that the release has specific tags so that if they are using tags, you can focus on specific ones of note, or you can use a more generic approach (e.g. semantic version) to determine which release to retrieve.
Hope that helps. GitLab has a rich API. Take a look.
We are wanting to use Branch for ad attribution - particularly for SKAdNetwork as per Branch's recommendation here - https://help.branch.io/using-branch/docs/branchskadnetwork-integration-instructions#app-option-1-use-the-branch-sdk-to-manage-skadnetwork
At the same time, we'd like to use Facebook's AEM (Aggregated Event Measurement).
So Question 1: can Branch handle AEM? I can only find one reference in Branch's documentation to AEM (here: https://help.branch.io/faq/docs/will-branch-support-pcm-or-aem) and (unless I'm misunderstanding) it seems out of date (in the sense that it only references AEM as an app-to-web technology, when Facebook themselves describe it as web-to-app or app-to-app).
If the answer to Question 1 is no, Question 2 is: If I install the Facebook SDK, will that take over the SKAdNetwork implementation, or will it work nicely side-by-side with Branch?
I’ve heard back from the Branch team separately and they’ve told me that:
Branch does NOT automatically support Facebook AEM, and that the Facebook SDK must be installed and
The Facebook SDK will work fine side-by-side with Branch.
Here are the answers I can provide so far.
Q1: Yes. Facebook's Aggregated Event Measurement framework is designed to provide web-to-web and app-to-web / app-to-app measurement.
We do not need to answer Question 2.
For bitcoin, the release page:
https://github.com/bitcoin/bitcoin/releases
I can get github release rss seed by append ".atom" on it
https://github.com/bitcoin/bitcoin/releases.atom
But this will include pre release tags.
How can I get latest release tag only?
Pre-releases are listed in the releases.atom feed, but they are not marked as pre-releases (no way to separate a pre-release from a final release as far as I can tell).
This information is instead available from the GitHub API.
you'll have to resort to the API.
unbelievable that such an essential feature is missing from the Atom feeds
May I suggest lastversion?
The lastversion utility is actually capable of detecting pre-releases from GitHub atom feeds alone, by looking at beta version identifiers in the tags.
It does use API as well for attempting to try returning more data from a release.
Does anyone know what is the difference between a GitHub release and the actual release that software company announces?
I'm trying to find the different versions of vue.js, on the vue.js official website there are only two versions but on the GitHub repository many releases I was wondered if the two concepts are different?
Release(may be downloadable link) version is just file which is uploaded.
Just they decide to provide only two version(may be latest) on official site.
It is all. If same version, (should be) same file. It is just like top selling tag on a store.
When they release a GitHub version, it is supposed to be open source. The one the company releases may have more code they have not reeased yet or is confidential.
Is there a way to automatically generate a change log from Github issues?
Ideally I want to be able to point at a closed milestone and generate either a plain text list of closed issues with their titles or, even better, a list with markup for links to the issues and the title of the issues themselves.
You can try to use Github-Changelog-Generator. (I'm author of this project)
It generates changelog from tags and merged pull-requests.
This script also have a support of GitHub Issues.
This changelog was generated by this script. CHANGELOG.md
Example:
Changelog
1.2.5 (2015-01-15)
Full Changelog
Implemented enhancements:
Use milestone to specify in which version bug was fixed #22
Fixed bugs:
Error when trying to generate log for repo without tags #32
Merged pull requests:
PrettyPrint class is included using lowercase 'pp' #43 (schwing)
support enterprise github via command line options #42 (glenlovett)
This isn't for Github specifically, but through Git you can run the log through pretty print to generate a changelog style html page.
From https://coderwall.com/p/5cv5lg
git log v2.1.0...v2.1.1 --pretty=format:'<li> view commit • %s</li> ' --reverse | grep "#changelog"
You can use the GitHub API to get a list of issues associated with a given milestone.
For example:
curl https://api.github.com/repos/<user>/<project>/issues\?milestone\=1\&state\=closed
replace <user> and <project> with the username and project and this will return a json list of all closed issues of the milestone with the id 1. You can then, for example, use a script to extract the information you are interested. Here is a python example that prints the list of issues as restructured text:
import json
with open("issues.json") as of:
data = json.load(of)
for issue in data:
t = issue['title']
n = issue['number']
url = issue['html_url']
print "* %s [`Issue %s <%s>`_]" % (t, n, url)
See if the following tool will do for you github-changes.
Disclosure: I'm the author of the tool.
We created an open source project to generate changelog from the list of closed github issues since a given datetime. It's available here: https://github.com/piwik/github-changelog-generator
Not directly through GitHub: that would be a kind of hook that you could put in place, and which would based on naming convention or comment convention that your project might follow.
Even using the issues title isn't always a sure way to generate meaningful change log, unless you review and edit if needed each and every issue title of your project.
In other words, it is very dependent on how you manage your project and not easily generalized to all GitHub repos.
I said as much in a very similar question "Publish a project release (binary/source packages) on Github?".
In addition of a third-party solution (or a GitHub Action like generate-changelog), you might soon Q3 2021, have a native feature from GitHub:
One of the most important parts of the software lifecycle is releasing your code for others to consume.
GitHub Releases will make that even easier by providing compelling and automatic release notes.
When creating a Release, you can click a button to automatically generate release notes.
If you want something more custom, you can a REST API to get the generated release notes and integrate them into your existing releases process.
We also want to ensure that these release notes look amazing when a maintainer shares them and make them easier to discover. We have done a complete redesign of releases to make projects announcements look stunning.
We are surfacing these releases in the feed to increase discovery.
We are also improving the open graph data for releases so they look equally fantastic when shared off of the GitHub platform.
Intended Outcome
Our number one goal is to make it easy for maintainers to create great release notes so more people can discover that amazing work maintainers are doing.
With minimal effort many projects will be able to benefit from detailed release notes.
For maintainers who put more time into their release notes to write editorialized content the intended outcome is that we free up time they are currently spending to maintain custom infrastructure and compile a changelog so they can focus on the most important content for their customers, high quality editorialized content.
Our other goal is to ensure that the release notes look great and are something maintainers and developers are excited to read and share.
How will it work?
The new Releases UI will be able to be enable with feature preview
A new button in the Release creation UI will be able to be pressed to generate release notes from any tag
The generated notes will be able to be configured via a .github/release.yml
A new REST API will allow customers to generate notes at their own convenience to further automate and customize the experience with GitHub actions.
I helped build a jQuery plugin for this recently that uses GitHub issues to communicate app updates directly to the user. The repo can be found here https://github.com/uberVU/github-changelog
Usage is pretty simple:
$(function() {
var $demoChangelog = $('.demo-changelog');
//call the plugin on a dom none
$demoChangelog.changelog({
//give it a repo to monitor
githubRepo: 'uberVU/github-changelog-playground',
});
//manually check for new closed issues
$('.demo-button').on('click', function(e) {
e.stopPropagation();
$demoChangelog.changelog('checkForUpdates');
});
});