We are ready to release OTB version MAJOR.MINOR.PATCH. The following steps need to be done:
### 1. Branches
*[ ] **(if major or minor release)** Feature freeze: [create the new release branch](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#create-release-branch)
* [ ] **(if patch release)** Work on the already existing branch `release-MAJOR-MINOR`
* [ ] Make sure the version number in `CMakeLists.txt` is MAJOR.MINOR.PATCH
### 2. Housekeeping
* [ ] In this story, make a list of blocking issues for the release (if any)
*[ ] [Update dashboard scripts](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#dashboard) to support new version numbers
*[ ] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive)(if needed)
* [ ] Update release notes (walk the GitLab MR merged history and log all improvements)
* [ ] Update the date in RELEASE_NOTES.txt
*[ ] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
*[ ] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
*[ ] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
*[ ] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [ ] Windows
* [ ] Linux
* [ ] Mac
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
*[ ] [Tag the release or RC](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [ ] **(if major or minor release)**: Merge the release into develop
* [ ] **(if it's the latest release)**: Merge the release into master
* [ ] **(if patch release)**: Backport fixes
* [ ] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
*[ ] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
*[ ] Upload OTB source archive to [Zenodo](https://zenodo.org/) to create a unique Digital Object Identifier (DOI)
* [ ] Update OTB-Data-Examples.tgz on orfeo-toolbox (packages)
* [ ] Send email to mailing list to announce the release
* [ ] Release announcement on the blog
* [ ] Announcement on social networks (twitter, google+)
*[ ] Forward announcement to news_item@osgeo.org ([OSGeo news](https://www.osgeo.org/foundation-news/))
* [ ] Plan the next release (nominate new release manager, setup PSC meeting on IRC)
*[ ] Contact QGis processing plugin maintainer to update XML description for new OTB-Applications (or [supply it](https://wiki.orfeo-toolbox.org/index.php/QGIS_access_to_OTB_applications#updating-the-XML-descriptors))
* [ ] Remove public branches related to MR or bugfix merged before the release
@@ -177,3 +177,21 @@ Regarding labels, we use the following set:
* ~"To Do": action is planned
* ~Doing: work in progress
* ~api ~app ~documentation ~monteverdi ~packaging ~qgis: optional context information
## Versioning
Starting from OTB 7.0.0, we use [semantic versioning](https://semver.org/). See the website for the full spec, in summary:
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> 1. MAJOR version when you make incompatible API changes,
> 2. MINOR version when you add functionality in a backwards-compatible manner, and
> 3. PATCH version when you make backwards-compatible bug fixes.
>
> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
The develop branch is always the place where the upcoming major or minor release is worked on. Patch releases are done on release branches, for example 7.0.1 and 7.0.2 could be found on the release-7.0 branch.
For the purpose of defining backwards compatibility, the OTB API covers (not an exhaustive list): the C++ API, the Python bindings, application names, application parameters, output format and interpretation of input data.
When we deprecate part of our public API, we should do two things: (1) update our documentation to let users know about the change, (2) issue a new minor or major release with the deprecation in place.
The CMakeLists.txt file is mandatory. It contains only a few things.
First, it declares a new CMake project with the name of the module.
First, it declares a new CMake project with the name of the module.
\begin{verbatim}
project(TheModuleName)
\end{verbatim}
Second, if the module contain a library (see src folder section below), it initializes the TheModuleName\textunderscore LIBRARIES CMake variable (if your module only contains headers or template code, skip this line):
Second, if the module contain a library (see src folder section below), it initializes the TheModuleName\textunderscore LIBRARIES CMake variable (if your module only contains headers or template code, skip this line):
You can build your remote modules inside the OTB source tree by copying your
source inside the directory \textit{Module/Remote} or against an existing OTB
build tree (note that it does not work with an install version of OTB).
build tree (note that it does not work with an install version of OTB).
The configuration below will handle both cases and take care of all the CMake
plumbing of the module:
...
...
@@ -68,7 +68,7 @@ plumbing of the module:
\end{verbatim}
The overall file should look like this:
\begin{verbatim}
cmake_minimum_required(VERSION 2.8.9)
project(TheModuleName)
...
...
@@ -85,14 +85,14 @@ if(NOT OTB_SOURCE_DIR)
\section{The include folder}
The include folder will contain all your headers (*.h files) and template method boy files (*.hxx or *.hxx). It does not require any additional file (in particular, no CMakeLists.txt file is required).
The include folder will contain all your headers (*.h files) and template method boy files (*.hxx or *.hxx). It does not require any additional file (in particular, no CMakeLists.txt file is required).
\section{The src folder }
The src folder contains the internal implementation of your module :
The src folder contains the internal implementation of your module :
\begin{itemize}
\item It typically contains cxx source files that will be compiled into a library.
\item It typically contains cxx source files that will be compiled into a library.
\item It can contain header files for classes used only within the implementation files of your module. Any header file present in the src folder will not be installed, and will not be available to other modules depending on your module.
\end{itemize}
...
...
@@ -100,7 +100,7 @@ If your modules is made of template only code, you do not need a src folder at a
If present, the src folder requires a CMakeLists.txt file.
The first part of the CMakeLists.txt file is classical, as it builds the library and links it:
The first part of the CMakeLists.txt file is classical, as it builds the library and links it:
GIT\textunderscore TAG the\textunderscore git\textunderscore revision\textunderscore to\textunderscore checkout
)
\end{verbatim}
This file should be provided along with your remote module inclusion proposal email to the otb-developers list. Please refer to the contributors guidelines for more information (next section).
This file should be provided along with your remote module inclusion proposal email to the otb-developers list. Please refer to the contributors guidelines for more information (next section).
