GitHub Procedures: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
No edit summary
Line 9: Line 9:
This is the procedure to make a "public release" for a GitHub-hosted project. This type of releases are accessible via the GitHub project page -> "releases" tab. The release procedure assumes that the release tag was already applied to the repository, either manually or via [[nort]]. At the time of the writing, [[nort]] is being extended to automate this procedure.
This is the procedure to make a "public release" for a GitHub-hosted project. This type of releases are accessible via the GitHub project page -> "releases" tab. The release procedure assumes that the release tag was already applied to the repository, either manually or via [[nort]]. At the time of the writing, [[nort]] is being extended to automate this procedure.


==Procedure==


Project Home -> "releases" tab -> "Draft a new release"


Draft a new release
Copy and paste the release tag from the local release procedure output. The format is similar to "release-4.2.2".


Copy and paste the release tag from the local release procedure output.
Upon pasting it into the release input box, the site should recognize it as "Existing tag".


Tag: release-1.0.3
Release title: 4.2.2


The logic should recognize it as "Existing tag"
Describe the release:


Release title: 1.0.3
Specify Introduced features and defect fixes. This will be part of the release history. Projects maintain notes to be consolidated into the release announcement in <tt>./doc/release-notes.txt</tt>. Copy and edit the content from there.


Describe the release: Introduced features, bug fixes. This will be part of the release history. Projects maintain notes to be consolidated into the release announcement in <tt>./doc/release-notes.txt</tt>.
Attached files:
* If is an installable release, attach binaries: "Attach binaries by dropping them or selecting them."
* If it is a library release, don't attach anything, as the libraries can be recreated from the tagged source tree, and in the future, we'll publish to a public Maven repository.
 
"Publish release"


Clean <tt>./doc/release-notes.txt</tt> and commit.
Clean <tt>./doc/release-notes.txt</tt> and commit.
Line 31: Line 37:
git push
git push
</pre>
</pre>
If is an installable release, attach binaries: "Attach binaries by dropping them or selecting them."
If it is a library release, select the JAR and the source JAR from the project's target directory and attach them.
Publish release.

Revision as of 20:17, 28 November 2016

Internal

Making a Public Release

Overview

This is the procedure to make a "public release" for a GitHub-hosted project. This type of releases are accessible via the GitHub project page -> "releases" tab. The release procedure assumes that the release tag was already applied to the repository, either manually or via nort. At the time of the writing, nort is being extended to automate this procedure.

Procedure

Project Home -> "releases" tab -> "Draft a new release"

Copy and paste the release tag from the local release procedure output. The format is similar to "release-4.2.2".

Upon pasting it into the release input box, the site should recognize it as "Existing tag".

Release title: 4.2.2

Describe the release:

Specify Introduced features and defect fixes. This will be part of the release history. Projects maintain notes to be consolidated into the release announcement in ./doc/release-notes.txt. Copy and edit the content from there.

Attached files:

  • If is an installable release, attach binaries: "Attach binaries by dropping them or selecting them."
  • If it is a library release, don't attach anything, as the libraries can be recreated from the tagged source tree, and in the future, we'll publish to a public Maven repository.

"Publish release"

Clean ./doc/release-notes.txt and commit.

cat /dev/null > ./doc/release-notes.txt
git add ./doc/release-notes.txt
git commit -m "cleaned ./doc/release-notes.txt post-release"
git push