<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="Secondary-Master-Node" />
  </query-continue>
  <query>
    <pages>
      <page pageid="133" ns="0" title="Release Management">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">= Release Cycles =
Each release cycle should follow this pattern:
# '''Development''' (2 - 4 Weeks): During this phase, new functionalities are developed.
# '''Testing and bug fixing''' (1 - 2 Weeks): This gives time for the users to test and the time bug fixing and a quick retest.

= Versioning =
[http://semver.org/ Semantic Versioning]:
Given a version number MAJOR.MINOR.PATCH, increment the:
* MAJOR version when you make incompatible API changes,
* MINOR version when you add functionality in a backwards-compatible manner, and
* 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.

* &lt;s&gt;Scheme: major.minor.patch, example: &lt;code&gt;1.2.3&lt;/code&gt;.&lt;/s&gt;
* &lt;s&gt;Odd minor version numbers denote development/unstable branches. For example, stoney cloud 0.8.x is considered stable, while stoney cloud 0.9.x is considered development/unstable.&lt;/s&gt;
* New features are added to unstable/development versions only.
* We have separate version numbers for the separate components (installer, online-backup, ldap-schemas, ...).

We start with '''0.1.0''' for development and '''0.2.0''' for first stable release.

= Development Procedure =
We have a minimum of two branches:
# Trunk (development): Master branch, normally without name tags, for testing reasons we set tags: v0.5.0_pre1
# Branch 1 to N (stable branch(es) for bug fixing): v0.2, the tag for a release would be: v0.2.1 to v0.2.N
# Branch 2 (second stable branch for bug fixing): v0.4, the tag for a release would be: v0.4.1 to v0.4.N


This results in the following development procedure:
* Features are scheduled on the individual module [[:Category:Roadmap|roadmap]] pages for implementation in specific future stable versions and are implemented (and tested) in development versions.
* A new major version will be released, when all features and goals specified for this version are implemented and tested.

TBD: Describe stable and unstable in more detail

= Development =
== Source Code Organization ==
All stoney cloud related source code is located on GitHub under https://github.com/stoney-cloud. To avoid clashes with over projects, every repository has the default prefix '''stoney-'''.

Some operating system related examples:
* https://github.com/stoney-cloud/stoney-gentoo-overlay
* https://github.com/stoney-cloud/stoney-gentoo-portage

The main framework called [[:Category:stoney core|stoney core]], which is responsible for shared functionality (like user management, rights and roles).
* https://github.com/stoney-cloud/stoney-core
* https://github.com/stoney-cloud/stoney-core/api (REST API)
* https://github.com/stoney-cloud/stoney-core/cli (Command Line Interface)
* https://github.com/stoney-cloud/stoney-core/web (Ajax based web interface)

Then we have the [[:Category:Self-Service Modules|Self-Service Modules]] with [[:Category:stoney backup|stoney backup]] as an example. This Self-Service Module provides an on-line backup service for desktops, servers and virtual machines.
* https://github.com/stoney-cloud/stoney-backup
* https://github.com/stoney-cloud/stoney-backup/api (REST '''a'''pplication '''p'''rogramming '''i'''nterface)
* https://github.com/stoney-cloud/stoney-backup/cli ('''c'''ommand '''l'''ine '''i'''nterface)
* https://github.com/stoney-cloud/stoney-backup/helpers (helper scripts and programmes)
* https://github.com/stoney-cloud/stoney-backup/provisioning (scripts and programmes to provision services)
* https://github.com/stoney-cloud/stoney-backup/web (Ajax based web interface)

See the [[Modularisation]] page for further details.

== Committing / Git Workflow ==
We follow the Git branching model according to: http://nvie.com/posts/a-successful-git-branching-model/

Each change-set in the git repository (and thus each commit) ideally contains only one concise and consistent change.
The commit-message precisely describes the change. If the change is in respond to a bug-report or feature-request, the number of the bug-report or feature-request is included.

== Scrum Labels ==
* '''Not Started''': not yet assigned to or accepted by any member.
* '''Assigned''': being assigned to or accepted by a member.
* '''In Progress''': being implemented.
* '''To Verify''': implementation done and now it is time for testing/verifying.
* '''Done''': ticket is verified.

== Testing ==
Testing is done in a clean test environment and '''not''' in a developer environment.
This means: all changes have to be committed to the git repository first and checked out from there in the test environment for proper testing.

* tests can be run on different levels
** framework-level (symfony/php unit tests)
** API-level:
*** JSON Schema compliance
*** client-test via [http://frisbyjs.com/ frisby.js]

== Bug-Reporting/-Workflow ==
Bugs are to be reported on the modules issue tracker on GitHub.

Ideally we have someone who acts as the Bug-Wrangler. His tasks are:
* go over unassigned bugs and properly assign them (since we can't expect users to properly assign bugs)
* discover and close duplicated, invalid or otherwise inappropriate bugs (so the Bug-Wrangler must have search-fu)
* request more information from the user if necessary (like the version of involved components, canned responses can be used/saved in the GitHub issue tracker for that purpose)
* request time estimates from developers
* kick developers and testers and make sure the issue-list stays short (therefore it would make sense if it's someone from stepping stone GmbH)
* manage the priority of bugs if necessary


[[Category:Development]]</rev>
        </revisions>
      </page>
      <page pageid="370" ns="0" title="SPICE">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">SPICE (Simple Protocol for Independent Computing Environments) began as an alternative to RDP, VNC and similar technologies. 

[[Category:Glossary]]</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>