Developer Info: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
Line 33: Line 33:
* [[Migrating source code from SVN to git]]: How to move a large project from SVN to git and keep the history, commits, branches and tags.
* [[Migrating source code from SVN to git]]: How to move a large project from SVN to git and keep the history, commits, branches and tags.


'''Note''': ''The following is all about using Subversion and is out of date as of November 2014 when we switched to git. There are still good ideas here...''
* [[TrunkDevelBranchRel | Using the SVN trunk, branches and tags to manage releases]].
* [[ShrewBranchGuide | Making a Branch of Shrew for a Server Release]]. Releases should be made from the trunk and moved to a branch once they are 'ready' so that development can continue on the trunk and so that we can easily go back to the software that mad up a release, fix bugs, and (re)release those fixes. In general, it's better to fix things like build issues, etc., discovered in the released software ''on the trunk'' and merge those down to the release branch to maintain consistency, re-release, etc. This also means that virtually all new feature development should take place on special ''feature'' branches, not the trunk.
* [[ReleaseGuide | Making a Source Release]]. Once software is ready for distribution, use this checklist to make sure you do all of the steps needed to make a source release.
* [[ReleaseGuide | Making a Source Release]]. Once software is ready for distribution, use this checklist to make sure you do all of the steps needed to make a source release.
* [[MergingBranches |How to merge code]]
* [[MergingBranches |How to merge code]]
Line 41: Line 38:
===== Making specific kinds of packages for release: =====
===== Making specific kinds of packages for release: =====
* [[RPM |Making RPM Distributions]]. Follow these steps to create an RPM distribution of the software.
* [[RPM |Making RPM Distributions]]. Follow these steps to create an RPM distribution of the software.
* [[Hyrax Package for OS-X]]. This describes how to make a new OS/X 'metapackage' for Hyrax.
* [[XP| Making Windows XP distributions]]. Follow these directions to make Windows XP binaries.
* [[OLFSReleaseGuide| Making a Release of OLFS]]. Follow these steps to create the three .jar files needed for the OLFS release. Includes information on how to build the OLFS and how to run the tests.
* [[OLFSReleaseGuide| Making a Release of OLFS]]. Follow these steps to create the three .jar files needed for the OLFS release. Includes information on how to build the OLFS and how to run the tests.
* [[ReleaseToolbox |Making a Matlab Ocean Toolbox Release]].  Follow these steps when a new Matlab GUI version is ready to be released.


===== Software process issues: =====
===== Software process issues: =====
Line 57: Line 51:
* [[NetworkServerSecurity |Security Policy and Related Procedures]]
* [[NetworkServerSecurity |Security Policy and Related Procedures]]
* [http://semver.org/ Software version numbers]
* [http://semver.org/ Software version numbers]
===== Old information =====
'''Note''': ''The following is all about using Subversion and is out of date as of November 2014 when we switched to git. There are still good ideas here...''
* [[TrunkDevelBranchRel | Using the SVN trunk, branches and tags to manage releases]].
* [[ShrewBranchGuide | Making a Branch of Shrew for a Server Release]]. Releases should be made from the trunk and moved to a branch once they are 'ready' so that development can continue on the trunk and so that we can easily go back to the software that mad up a release, fix bugs, and (re)release those fixes. In general, it's better to fix things like build issues, etc., discovered in the released software ''on the trunk'' and merge those down to the release branch to maintain consistency, re-release, etc. This also means that virtually all new feature development should take place on special ''feature'' branches, not the trunk.
* [[Hyrax Package for OS-X]]. This describes how to make a new OS/X 'metapackage' for Hyrax.
* [[XP| Making Windows XP distributions]]. Follow these directions to make Windows XP binaries.
* [[ReleaseToolbox |Making a Matlab Ocean Toolbox Release]].  Follow these steps when a new Matlab GUI version is ready to be released.


== About Subversion ==
== About Subversion ==
* [http://svnbook.red-bean.com/en/1.7/index.html Subversion 1.7 documentation] -- The official Subversion documentation; [http://svnbook.red-bean.com/en/1.1/svn-book.pdf PDF] and [http://svnbook.red-bean.com/en/1.1/index.html HTML].
* [http://svnbook.red-bean.com/en/1.7/index.html Subversion 1.7 documentation] -- The official Subversion documentation; [http://svnbook.red-bean.com/en/1.1/svn-book.pdf PDF] and [http://svnbook.red-bean.com/en/1.1/index.html HTML].
* [[OPeNDAP's Use of Trac]] -- How to use Trac's various features in the software development process.
* [[OPeNDAP's Use of Trac]] -- How to use Trac's various features in the software development process.

Revision as of 16:42, 20 September 2015

  • Nightly Builds: Software we build every night on several platforms. The link provides the most recent report for each build we do. Use show=current to get the most recent; show=<date> to get a particular date, show=<platform> to see a particular platform. The sort=yes option runs the results through Unix sort before building the table. The nightly build software is part of the nbuilds project and is available from our trac/svn repository.

Developer Guidelines and Information

The OPeNDAP FAQ has a pretty good section on developer's questions, especially regarding SVN.

General development information

These pages contain general information relevant to anyone working with our software:

Older information - most of these pages describe building Hyrax using source code checked out from our SVN repository. The newer pages (above) that describe using source from GitHub are probably what you want. These pages, however, have some potentially useful information about the third-party code you need if building on an older version of Linux or OS/X.

Workshops

  • The APAC/BOM Workshops: This workshop spanned several days and covered a number of topics, including information for SAs and Developers. Oct 2007.
  • ESIP Federation Server Workshop: This half-day workshop focused on server installation and configuration. Summer 2008
  • Server Functions: This one-day workshop is all about writing and debugging server-side functions. It also contains a wealth of information about Hyrax, the BES and debugging tricks for the server. Spring 2012. Updated Fall 2014 for presentation to Ocean Networks Canada.

Development process information (OPeNDAP Specific)

These pages contain information about how we'd like people working with us to use our various on-line tools.

Using revision control:
Making specific kinds of packages for release:
  • Making RPM Distributions. Follow these steps to create an RPM distribution of the software.
  • Making a Release of OLFS. Follow these steps to create the three .jar files needed for the OLFS release. Includes information on how to build the OLFS and how to run the tests.
Software process issues:
Old information

Note: The following is all about using Subversion and is out of date as of November 2014 when we switched to git. There are still good ideas here...

About Subversion