Difference between revisions of "Steps for an official release"
From OpenEMR Project Wiki
Bradymiller (talk | contribs) |
Bradymiller (talk | contribs) |
||
Line 47: | Line 47: | ||
==9. Build the tar.gz, zip and deb packages from v4_1_2.== | ==9. Build the tar.gz, zip and deb packages from v4_1_2.== | ||
:Here is a script that automates the | :Here is a script that automates the release builds below: | ||
:*http://gist.github.com/bradymiller/5786409 | :*http://gist.github.com/bradymiller/5786409 | ||
Revision as of 11:59, 16 June 2013
Overview
Steps detailing a release (4.1.2 is given as an example).
1. Create a rel-412 branch from master in the git repo.
2. Release an online development demo that uses the rel-412 branch and updates daily.
- Also provide links for downloading rel-412 daily builds/packages(zip and tarball) to allow testing of installation and upgrading by testers
3. Publish installation, upgrade, and downloading instructions
- Also update the INSTALL file
4. Finalize the translations in the rel-412 branch.
5. Bug fix and finalize the rel-412 branch.
- Update the copyright/acknowledgements page by copying the copyright page from HERE to acknowledge_license_cert.html in openemr codebase
6. Create a list of new features in the rel-412 branch (since the last official release)
7. Prepare files for the Ubuntu/debian package
- Ensure following files are updated at openemr/contrib/util/ubuntu_package_scripts/production/ in codebase:
- control
- Update Version
- Update Installed-Size (just estimate it, doesn't need to be accurate)
- Add new package dependencies (if pertinent, for example in 4.1.0, adding php5-soap and also a Pre-Depends:debconf)
- README.Debian
- Change the dates at bottom of file to release date (use date -R to get correctly formatted date).
- changelog.Debian
- Add entry for new version:
openemr (4.1.2-1) stable; urgency=low * New upstream version -- Brady Miller <brady@sparmy.com> Fri, 25 Mar 2011 22:46:08 -0700
- copyright
- Add current date near top (use date -R to get correctly formatted date)
- Modify the copyright years (two of them), if needed
- preinst
- Update the algorithm to upgrade the previous version correctly
8. Release rel-412 branch by tagging in git repo with v4_1_2.
- Things to remember before tagging the release.
- Remove -dev from $v_tag (make it blank) in the version.php file
- Ensure the 'allow_debug_language' global in locale section in library/globals.inc.php is defaulted to 0
- Ensure the two User Manual links point to the correct online manual
- Login into the sourceforge shell and go to the git repo and type:
git tag v4_1_2 rel-412
9. Build the tar.gz, zip and deb packages from v4_1_2.
- Here is a script that automates the release builds below:
10. Release packages on sourceforge
- Upload via Project Admin
- Upload release and a release notes file
- Set file properties appropriately
11. Announce Release
- Sourceforge
- google+
- Linuxmednews
- Freecode