The path to 1.0.0

[eloquence]

We're not close to a 1.0.0 release yet, but I would suggest we look ahead as to what we would expect from such a release. Typically, a 0.x release series is used to denote a product still in active development, with breaking changes potentially introduced at any time, and core functionality still missing.

To me, a 1.0.0 milestone would imply a few things:

• platform support maturity across Windows/Mac/Linux/Qubes
• improved installation (ideally, smaller initial download size; if possible, avoiding the separate Docker installation requirement)
• a polished GUI that mitigates user error through clear affordances, by applying standard UX patterns like progressive disclosure, etc.
• a public threat model (potentially augmented by a more well-defined internal one)
• a public architecture diagram
• ideally, a completed independent security audit, highest priority findings addressed
• a more polished visual identity

What's missing from that list? What's in it that maybe doesn't need to be in a 1.0.0 release?

[apyrgio]

I've been revisiting this post on and off, because while I like each item in the list, I find myself not being 100% sure if that constitutes Dangerzone 1.0.0. I mean, to my mind, achieving the above is a definite sign that Dangerzone is stable and mature. A 1.0.0 release is of course tangent to these concepts, but to me, it's mainly about setting expectations.

It means "From now on, I will make it clear when I break your workflow, or when I introduce a new feature". This applies both to the UX and the API. And implies that "I do not plan to make radical changes right away". That's at least how I interpret SemVer's wording on this subject:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

(see also this interesting discussion: semver/semver#734)

---

With this angle in mind, I'll comment on the above points:

platform support maturity across Windows/Mac/Linux/Qubes 👍

I guess this mainly applies to Qubes, and how users install Dangerzone and update it. So yes, I agree that having Qubes support on par with other systems is a 1.0.0 requirement.

improved installation (ideally, smaller initial download size; if possible, avoiding the separate Docker installation requirement) 🤔

I think that shrinking the image is not a 1.0.0 requirement (even though I hate our large images). Using a different container runtime than Docker on MacOS/Windows (if we do choose to go down that road) is indeed a major version bump (either 0 -> 1 or 1 -> 2). But if this is not something that is in our immediate plans, I would not make this a strict requirement.

a polished GUI that mitigates user error through clear affordances, by applying standard UX patterns like progressive disclosure, etc. 🤔

This is a pretty interesting item, and a thorn against my reading of SemVer 1.0.0. Our GUI does not constitute an API, yet it's the main way people use Dangerzone. SemVer does not take this into account. Still, since we've broaden the concept of SemVer to "breaking expectations" than just "breaking programmatic interface", I'd suggest that we treat any breaking change to the way user's use our UI as a major version bump. Some examples are changing the existing workflow to a large extent, or making a major UX overhaul.

So, is this item a 1.0.0 requirement? I'd say only if we plan to change our sanitization workflow (may happen if we want to target document previewing now, else no) or if we radically change our UX (this is part of our short term plans, so maybe yes).

a public threat model (potentially augmented by a more well-defined internal one)
a public architecture diagram

I see these as a good to have, but I don't think they are a 1.0.0 requirement.

ideally, a completed independent security audit, highest priority findings addressed 👍

if the security audit finds something that undermines the way we perform sanitization and requires radical changes, I agree. This is also part of our short-term plans, so we'll find out soon.

a more polished visual identity

Again, this seems more of a good to have for me.

---

Finally, some honorary mentions:

1. Stabilizing the dangerzone-cli interface. This interface has not changed for a while, and there are people who already depend on it. I think we are safe to call it stable.
2. Creating a stable Python API for integrating Dangerzone as a sanitization library. People currently use Dangerzone as a separate process (dangerzone-cli), but not as a Python module (from dangerzone import ...). Having a Python API for Dangerzone, and uploading it to PyPI, would make things more interesting for adoption, and it's where SemVer would fit as well.

[deeplow]

Maybe also localization should be a requirement #665