ETS Names and Versioning

This wiki provides guidance on developing OGC Compliance tools.

Repositories for OGC Test suites

Within the OGC Compliance Program conformance tests are developed to test that implementations properly comply with OGC standards. Each test suite has its own repository in github. See here for more details.

Naming a repository

Tests Suites names follow this convention:

ets-[Abbreviation][MajorNumber][MinorNumber]

For example:

ets-gml32

• Abbreviation: Is the abbreviation of the standard. For example gml, wfs, wms
• Major Number: Is the Major version number of the main specification. For example for GML 3.2.1 is 3 and for WFS 2.0 is 2
• Minor Number: Is the Minor version number of the main specification. For example for GML 3.2.1 is 2 and for WFS 2.0 is 0

A test suite should apply to any m.n implementation. Test suites in GitHub can be found by following this URL:

https://github.com/opengeospatial/[name]

For example:

https://github.com/opengeospatial/ets-wcs10

Naming of test suites with parts

Regular pattern shall be used. In addition, the part with number is added to the name (right behind a '-').

Thus, the convention is:

ets-[Abbreviation][MajorNumber][MinorNumber]-[partPlusNumber]

For example:

https://github.com/opengeospatial/ets-citygml30-part2

Naming of test suites for profiles

The same pattern as for non profile test suites shall be used but, in addition, the abbreviation of the profile has to be added to the name (right behind a '-'). Before that, the abbreviation of the standard the profile bases on must be used.

If there are more than one base standards, the most general one shall be picked for the name.

Thus, the convention is:

ets-[Abbreviation-of-base-standard][MajorNumber][MinorNumber]-[Abbreviation-of-profile][MajorNumber][MinorNumber]

For example:

ets-wfs20-dgiwg20

Versioning of test suites

Every time there is a new release of the test, the code should be tagged following the convention explained in this section.

The revision number uses a double digit number, where m and n are non-negative integers:

    m.n

The version depends on the state of the test. If the test is in beta and has not been released, the version should be <1.0:

• In development (It as not been approved by OGC): 0.n (e.g. 0.2,0.3,..)
• Approved by the TC (for compliance certification): m.n (e.g. 1.0)

n is incremented whenever:

• a bug is fixed
• an existing test is refactored or enhanced

m is incremented whenever:

• new tests are added (either to existing conformance classes or in new ones). New conformance classes can be added after a test suite is initially approved

• The first version of a test is 0.1

The master branch contains the latest code; it must always build and should be stable enough that the test suite is runnable (even if not all tests have been fully verified). The version in master is:

	m.n-SNAPSHOT

For Example:

	1.0-SNAPSHOT

The version matches the milestone in the tracker.

Issues Management

Issues are capture for each test in their own repository. Once they are closed they are assigned a milestone. Issues are prioritize in weekly meeting with developers and OGC staff.