1. 2
    1. Why is there no pre-release versioning in Monotonic Versioning? - The pre-release behaviour of SemVer offers little semantic information about a release. Rather than pre-releases, Monotonic Versioning simply increments the compatibility number when a release breaks compatibility with an existing one.

    2. What if I want my API version numbers to be low? - That is silly, aesthetics have little place in versions where the point is to convey semantic information. If you want lower version numbers, get your API right earlier.

    If my interpretation of these points are correct, I’m not sure this lends well to public API experimentation. You could easily reach 10+ whilst experimenting with an API design in public.

    Beyond this, I’d like to have some space for API experimentation in public. Perhaps I could just decide that +alpha or something, may have breaks between release numbers, and make that clear for my usage of MonoVer.

    Maybe this is just aesthetics though, and I’m just thinking in old-fashioned SemVer brain. I’d love to be enlightened though.

    1. 5

      You could easily reach 10+ whilst experimenting with an API design in public.

      Why is that bad?

      1. 1

        I’m not sure it is. I think it’s my view on aesthetics. SemVer brain, I’ve not really used much else.

      2. 1

        I had the same feeling, but then taking a step back, I wondered how much of the API development would actually be done in public? Seems like most of my testing is internal or with a few clients, at which point I’m not making any compatibility guarantees. I would just bump the REVISION until I was ready to make a guarantee on API stabiliity, at which point it would become version 1 (or whatever is the next version)

        1. 1

          I’m not sure if this encourages bumping the revision number until you’re ready to make a guarantee, (or maybe it does and I’ve missed it?)