---
tags: ietf-scitt
---
###### tags: `ietf-scitt`

# SCITT: Artifact Versioning and Feeds

## Examples

To support the [SCITT Use Cases][use-cases], the follow examples are illustrated.

## Integrating SCITT With a Build System

Topics to cover:
- [ ] How to structure SCITT Feeds
- [ ] How to correlate each build artifact with previous versions
- [ ] How to group a collection of artifacts (client/server, service1, 2, 3)
- [ ] Where to store SCITT Receipts

> Note: This example uses the [net-watcher][net-watcher] Github repository

The [net-watcher][net-watcher] application serves multiple customer audiences through 2 supported versions across Windows and Linux servers.

- **Version 1** - Supports on-premise networks
- **Version 2** - Adds support for hosted cloud networks

Both major versions, on both platform maintain support, including minor fixes and security patching.

- Updates are not linear over time. A security patch `1.1.1` shipped after `2.2.0` had already shipped.
- Not all users of Version `1.0.0` can move to the `2` release as some incompatibilities were introduced and features were added that require the customer to pay for the upgrade
- A new `Version 3` has been started by the development team.

**net-watcher - Linux**

Version 1.0.0 --> Version 1.1.0 --> Version 1.2.0
                \             \
                 \              Version 1.1.1 --> Version 1.1.2 --> 
                  Version 1.0.1 --> Version 1.0.2...

Version 2.0.0 --> Version 2.1.0 --> Version 2.2.0
                              \
                                Version 2.1.1 --> Version 2.1.2 --> 

Version 3-alpha -->

**net-watcher - Windows**

Version 1.0.0 --> Version 1.3.0 --> Version 1.4.0
                             \
                              \ Version 1.3.1 --> Version 1.3.2

Version 2.0.0 --> Version 2.1.0
 \
   Version 2.0.1 --> Version 2.0.2 --> 

Version 3-alpha -->

**[TODO]:** Add CalVer examples

### Questions
- [ ] How does a producer declare version `1.1.0` supersedes `1.0.0`
- [ ] How does a producer declare version `1.0.2` supersedes `1.0.1` and `1.0.0`
- [ ] How does a producer make statements, unique to each version of the `net-watcher` product?
- [ ] For each release, how does the development team structure their SCITT Feed?
- [ ] How does a developer group a collection of like services?
- [ ] Is each build/version a unique Feed?
- [ ] Is there a way to make a continuous stream for a specific release?
- [ ] Is the concept of version bands in scope for SCITT?
- [ ] If not in scope, will the application platforms have to unique solve this for each?

### References

- [calver.org](https://calver.org/)
- [semver.org](https://semver.org/)

[use-cases]: https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/
[net-watcher]: https://github.com/wabbit-networks/net-watcher