Process for Changes

Table of Contents

What to do, if you have an idea for a change
How to prepare a change request
Preparing a pull request
Process for the integration of a pull request
Documentation typos etc
Minor releases and major releases
Keeping the documentation and the xsd in sync
Continuous integration with TravisCI

# What to do, if you have an idea for a change Use the template to fill in a change request and send it by eMail to us. If you already have a pull request for the changes in the schema it is better. But perhaps you want to first consult with the SIRI WG, if the change has a chance to be accepted.

We don't use the issues capabilities of GitHub currently.

# How to prepare a change request * Copy the template: https://public.3.basecamp.com/p/nK4pAcR1yqsY6CDm7drHZmS3 * Make sure to check, that the change is not already in our pipeline (https://public.3.basecamp.com/p/pwE1d4xLg73t1nMHrT6wLWEJ) * Only pack one change in one pull request or CR document. * Send it to us (christophe.duquesne@aurigetech.com; bruns@vdv.de; Adrian.aeschbacher@sbb.ch) * Preferably we would like to get a full pull request that also works on the examples from you. * Open an issue, if you only can describe the problem. Also here a proposal for the solution is prefered. Sometimes an issue needs to be discussed in an early stage, then also an issue is the right way to start the conversation. Copy the structure of an existing issue. * As we need to synchronize the documentation with the xsd, we certainly need an issue for that anyhow. In that issue at least a filled in CR template must be added. Additional files/data can be added as necessary. * Reference the pull request in the issue and the issue in the conversation about the pull request # Preparing a pull request * Read: https://www.google.ch/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=2ahUKEwjIoLratc7kAhXjwAIHHaHpCfMQFjACegQIDBAG&url=https%3A%2F%2Fyangsu.github.io%2Fpull-request-tutorial%2F&usg=AOvVaw1pytuwEHL23Reyvoml2r6f * Make sure, that the xsd is validating after your changes * Make sure to have used the latest version for your changes. * Make sure the examples are also still valid. We will not accept pull requests that do not do that and we will test automatically. * Use xmllint for pretty-printing it in the way we need (we will automatize this step very soon) # Process for the integration of a pull request * We will link the CR in basecamp to the pull request. * Travis will validate the requests (and in future also to the prettifying) * The different members of the SIRI subgroup will "vote" on the pull request. They can add comments and add themselves as reviewers and make the review. * If necessary an update must be provided by the author. This can also concern the issue in the documentation. * If the reviews are in favour someone of the core group will merge the request into the main branch and update the documentation of the standard (in Basecamp) at the same time. The documentation change is noted. * The excel in basecamp must be updated afterwards. * To avoid edit conflicts on the document, the document name is changed with _checkout, when it is away for editing by somebody. The note says, who has the document. # Documentation typos etc * Such non-conflicting non-XSD related manners can be added as simple issues with a label "typo": https://github.com/SIRI-CEN/SIRI/issues # Minor releases and major releases * After a given number of change requests a new version is formed. * Minor releases will be shown with a new letter (e.g. v2.0o). This should be non-breaking changinges. * A version number in the second number is still minor. There should mainly be extensions and things that can easily adapted like enum (e.g. v.2.1a) * A major release with a new version (e.g. v3.0a) contains breaking changes. # Keeping the documentation and the xsd in sync For copyright reasons the full standards document can not be put here. We want all changes in the XSD also to be in the document at the same time. This means that a pull request is only merged, when at the same time the document(s) are adapted. In case of supporting lists, they will be in the repository as well and can be part of a pull request. # Continuous integration with TravisCI We will set up Travis: https://help.github.com/en/enterprise/2.17/admin/developer-workflow/continuous-integration-using-travis-ci When a branch is submitted as pull request this code is ran, and it it basically states if all tests work. This forces the user to make a commit regarding an XSD change and the appropriate XML example. The branch remains unmerged until the branch works against the continuous integration step.