Title: Javascript Release Documentation
This document describes the release guidelines for Apache Olingo OData Client for JavaScript (referenced in this document as ODataJS). This is similar to standard Apache procedures to release for Maven based projects at Apache, but since it is an JavaScript library it is adopted to be used with grunt js.
Apache Olingo is built and released with Node.js® in combination with grunt task runner
An Apache Olingo ODataJS release consists of:
Main artifact: <artifactId>-<version>.<ext>
A library artifact bundle containing all libraries necessary use the OData Client for JavaScript
Package formats: zip.
JavaScript Doc artifact: <artifactId>-<version>-doc.<ext>
A documentation bundle containing the documentation for the ODataJS library.
Package formats: zip.
Source artifact: <artifactId>-<version>-sources.<ext>
A source-release bundle containing all files the sources necessary to build all other artifacts.
Package formats: zip.
The documentation that will be part of the release must match the code. The documentation must be up-to-date. Release independend documentation is maintained on the Apache Olingo Documentation page.
A release manager must be appointed for a release. He or she is in charge of the release process, following the guidelines and eventually generating the release artifacts. The release manager might tailor the process for a specific release.
The Olingo community decides if the release will be a major or a minor release and agrees on a version number.
The artifactnames are build according the following rule:
artifactname : '${pkg.name}-${pkg.version}-${pkg.postfix}-${pkg.releaseCandidate}
pkg refers to the package.json file
name is the attribute name
version is the attribute version
postfix is the attribute postfix
isReleaseCandidate is the attribute releaseCandidate
package.json sample:
{
"name": "odatajs",
"version": "4.0.0",
"postfix": "",
"releaseCandidate" : "RC01",
...
}
Workflow for changing the release
<change package.json ..., "name": "odatajs", "version": "4.0.0", ... <change package.json ... , "postfix": "", "releaseCandidate" : "RC01", ... git add package.json git commit -am 'Issue OLINGO-25 - make release - set version 4.0.0-RC01' git tag -f 4.0.0-RC01 grunt release git push git push --tags
Release artifacts will be stored in the dist folder parallel to the olingojs folder.
There must not be any open JIRA issues for this release. There might be open issues for future releases.
The QUnit tests in odata-qunit-tests.htm tests must succeed on a clean machine with the c#.net testserver running.
Open http://localhost:4002/tests/odata-qunit-tests.htm in the browsers recommented ( Internet Explorer, Chrome, Firefox and Opera)
Each source code file must have a current ASF license header. The source code should follow the Apache Olingo code style. For verification run following Maven execution
``grunt license-check`` must be ok
NOTICE, LICENSE and DISCLAIMER must be present in all bundles and must be up-to-date.
MD5 and SHA files are created manually for distribution packages:
openssl md5 < ${filename}.zip > ${filename}.zip.md5
gpg --print-md SHA512 ${filename}.zip > ${filename}.zip.sha512
A tag has to be created for every release candidate. The naming rule for the tags is olingojs-${version}-${postfix}-RCxx. This is created as part of the Maven release process. The tag will be renamed to the final version number upon vote approval.
A branch has to be created for every release. The naming rule for this branch is olingojs-${version}-${postfix}. This has to be created manually upon release approval.
Once all preparations are done, a release candidate will be built.
All release candidates must be cryptographically signed. The string “-RCxx” will be attached to the version number of the release candidate artifacts, where is the number of the release candidate starting with 01. If more than one release candidate is required a new tag has to be created and release candidate number will be increased by one.
The release candidate artifacts:
Once candidate artifacts are available, release manager kicks off the [VOTE process][2].
If the vote fails, the raised issues will be fixed, a new release candidate will be built and the VOTE process will be restarted.
If the release candidate gets approved, we can proceed to release publishing.
This checklist helps verifying if a release candidate is valid:
After all questions of this checklist can be answered with yes it is OK to give a +1 on the mailing list. Of course the Release Manager can also use this checklist to make sure all artifacts are correct before publishing the results on the mailing list.
If the release candidate gets approved, we can proceed to release publishing:
http://olingo.apache.org/doap_Olingo.rdf
Results are shown here: