While thinking of how to go about writing Beah's release notes, it came to my mind that why don't we use GitHub release feature for that? [1]
What I have in mind is once we are done with the tagging, GitHub has a zip/.tar.gz ready. We could use GitHub's Web UI to do the entire release process and have a link from the beah docs.
I have zero experience with using this GitHub feature. They also have an API. So perhaps, we can do all of it with a script.
Thoughts? If this sounds encouraging, I could give it a shot and also we can adopt it for our other projects.
[1] https://github.com/blog/1547-release-your-software
Best, Amit.
Excerpts from Amit Saha's message of 2013-11-15 16:02:19 +1000:
While thinking of how to go about writing Beah's release notes, it came to my mind that why don't we use GitHub release feature for that? [1]
What I have in mind is once we are done with the tagging, GitHub has a zip/.tar.gz ready. We could use GitHub's Web UI to do the entire release process and have a link from the beah docs.
I have zero experience with using this GitHub feature. They also have an API. So perhaps, we can do all of it with a script.
Thoughts? If this sounds encouraging, I could give it a shot and also we can adopt it for our other projects.
We don't publish beah or rhts tarballs *anywhere* right now, so having them on GitHub would certainly be an improvement. But I would rather we just put them in http://beaker-project.org/releases/ alongside the beaker tarballs.
----- Original Message -----
From: "Dan Callaghan" dcallagh@redhat.com To: "Amit Saha" asaha@redhat.com Cc: "Beaker development" beaker-devel@lists.fedorahosted.org Sent: Friday, November 15, 2013 4:09:55 PM Subject: Re: [Beaker-devel] GitHub releases for peripheral/related projects
Excerpts from Amit Saha's message of 2013-11-15 16:02:19 +1000:
While thinking of how to go about writing Beah's release notes, it came to my mind that why don't we use GitHub release feature for that? [1]
What I have in mind is once we are done with the tagging, GitHub has a zip/.tar.gz ready. We could use GitHub's Web UI to do the entire release process and have a link from the beah docs.
I have zero experience with using this GitHub feature. They also have an API. So perhaps, we can do all of it with a script.
Thoughts? If this sounds encouraging, I could give it a shot and also we can adopt it for our other projects.
We don't publish beah or rhts tarballs *anywhere* right now, so having them on GitHub would certainly be an improvement. But I would rather we just put them in http://beaker-project.org/releases/ alongside the beaker tarballs.
Okay, so how does this sound:
1. Tag a new release 2. "Announce" a release using the Web UI 3. Get the tarballs from the GitHub repo and simply scp them to the above URL 4. Link the GitHub release announcement from the Beah docs and link to the tarballs above.
Perhaps the whole thing can be automated with the help of [1].
[1] http://developer.github.com/v3/repos/releases/
Thoughts? -Amit.
-- Dan Callaghan dcallagh@redhat.com Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
Excerpts from Amit Saha's message of 2013-11-15 16:19:37 +1000:
Okay, so how does this sound:
- Tag a new release
- "Announce" a release using the Web UI
- Get the tarballs from the GitHub repo and simply scp them to the above URL
- Link the GitHub release announcement from the Beah docs and link to the tarballs above.
Perhaps the whole thing can be automated with the help of [1].
[1] http://developer.github.com/v3/repos/releases/
Thoughts?
I think we need release notes ("announcements") in the beah docs, not just on GitHub, otherwise we are locked in to GitHub's proprietary release process.
All it needs is a new page "Changes" or "Release Notes" in the beah sphinx book, with a new entry added each time a new version is tagged. The process should just look like:
vim documentation/release-notes.rst git add documentation/release-notes.rst tito tag git push origin master beah-123 # some magic here to get the tarball published under # http://beaker-project.org/releases/
On 11/18/2013 11:22 AM, Dan Callaghan wrote:
Excerpts from Amit Saha's message of 2013-11-15 16:19:37 +1000:
Okay, so how does this sound:
- Tag a new release
- "Announce" a release using the Web UI
- Get the tarballs from the GitHub repo and simply scp them to the above URL
- Link the GitHub release announcement from the Beah docs and link to the tarballs above.
Perhaps the whole thing can be automated with the help of [1].
[1] http://developer.github.com/v3/repos/releases/
Thoughts?
I think we need release notes ("announcements") in the beah docs, not just on GitHub, otherwise we are locked in to GitHub's proprietary release process.
All it needs is a new page "Changes" or "Release Notes" in the beah sphinx book, with a new entry added each time a new version is tagged.
Yeah, something light, similar to an RPM changelog or the basic release history I publish for side projects:
http://contextlib2.readthedocs.org/en/latest/#release-history
When we split out the tasks repo, we should use a similar structure (i.e. create a ReadTheDocs project and include a change history for the individual tasks).
The process should just look like:
vim documentation/release-notes.rst git add documentation/release-notes.rst
Missing a "git commit" here :)
tito tag git push origin master beah-123 # some magic here to get the tarball published under # http://beaker-project.org/releases/
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2013-11-18 16:29:57 +1000:
On 11/18/2013 11:22 AM, Dan Callaghan wrote:
The process should just look like:
vim documentation/release-notes.rst git add documentation/release-notes.rstMissing a "git commit" here :)
tito tag
Actually it was intentional, so that the release notes get included with tito's "Automatic commit of beah-1.2.3..." commit. Just to keep the git history a little tidier (avoids "add release notes for beah 1.2.3" commits).
----- Original Message -----
From: "Dan Callaghan" dcallagh@redhat.com To: "Amit Saha" asaha@redhat.com Cc: "Beaker development" beaker-devel@lists.fedorahosted.org Sent: Monday, November 18, 2013 11:22:47 AM Subject: Re: [Beaker-devel] GitHub releases for peripheral/related projects
Excerpts from Amit Saha's message of 2013-11-15 16:19:37 +1000:
Okay, so how does this sound:
- Tag a new release
- "Announce" a release using the Web UI
- Get the tarballs from the GitHub repo and simply scp them to the above
URL 4. Link the GitHub release announcement from the Beah docs and link to the tarballs above.
Perhaps the whole thing can be automated with the help of [1].
[1] http://developer.github.com/v3/repos/releases/
Thoughts?
I think we need release notes ("announcements") in the beah docs, not just on GitHub, otherwise we are locked in to GitHub's proprietary release process.
All it needs is a new page "Changes" or "Release Notes" in the beah sphinx book, with a new entry added each time a new version is tagged. The process should just look like:
vim documentation/release-notes.rst git add documentation/release-notes.rst tito tag git push origin master beah-123 # some magic here to get the tarball published under # http://beaker-project.org/releases/
Do we want to link to the tarball from the releases page? I believe so. The problem here is (AFAICT) that we don't get the tarball filename until we tag it. Hence, I can't see how it can be done at the time of tagging. If tito had a --dry-run option for tagging that would be easy. I opened an issue with the project and have a patched version which works [1].
Here is what I have without involving GitHub in any way:
# tito tag --dry-run
# add changelog and archive download link git add documentation/release-notes.rst
# tito tag # git push tag
# create the .tar.gz release_tag=`git tag --points-at HEAD` git archive --format=tar.gz --prefix=$release_tag/ $release_tag >$release_tag.tar.gz
# upload it to beaker-project.org/releases scp $release_tag.tar.gz beaker-project.org:/path-to-releases/ (I see that releases is in .gitignore, so I believe it should be fine?)
Leaving aside the tarball filename, I think it's fairly straightforward now.
[1] https://github.com/dgoodwin/tito/issues/99
To summarize, here are the two options:
- Use the patched tito as per the above workflow - Use a separate commit after the tagging to add the download link
Any suggestions regarding the "problem" above welcome.
Best, Amit.
Excerpts from Amit Saha's message of 2013-11-19 12:23:56 +1000:
Do we want to link to the tarball from the releases page? I believe so. The problem here is (AFAICT) that we don't get the tarball filename until we tag it. Hence, I can't see how it can be done at the time of tagging. If tito had a --dry-run option for tagging that would be easy. I opened an issue with the project and have a patched version which works [1].
Well the tag which tito uses is not an inscrutable mystery :-) it is easily predictable (and indeed, you should know what version you are tagging *before* you tag it). It's going to be either x.y.z+1 if you let tito do the bumping, or else you bump it manually to whatever version you want and then use tito tag --keep-version to commit it.
Here is what I have without involving GitHub in any way:
# tito tag --dry-run
# add changelog and archive download link git add documentation/release-notes.rst
# tito tag # git push tag
# create the .tar.gz release_tag=`git tag --points-at HEAD` git archive --format=tar.gz --prefix=$release_tag/ $release_tag >$release_tag.tar.gz
# upload it to beaker-project.org/releases scp $release_tag.tar.gz beaker-project.org:/path-to-releases/ (I see that releases is in .gitignore, so I believe it should be fine?)
All the content on beaker-project.org needs to be tracked in git on the published branch. That lets us track and preview what will be published, and also gives us a backup (there are no full-disk backups for beaker-project.org). So scp'ing random stuff into the webroot defeats all that.
The tarballs should either be generated automatically during the web site build (like the ones for beaker are) or else committed to the web site source tree (this would be annoying because it's a lot more shuffling).
beaker-devel@lists.fedorahosted.org
-
Amit Saha -
Dan Callaghan -
Nick Coghlan