Should we tag 1.0 soon?

[mholt]

Any other outstanding issues before we tag v1.0.0?

[aabelix]

Totally! May I suggest including fix #112 that is required to support plugins for go compiler 1.17?

[aabelix]

Totally! May I suggest including fix #112 that is required to support plugins for go compiler 1.17?

This requested was rejected by #111.

[mholt]

I might want to look into maybe adding an embed feature before 1.0, now that Caddy's file server supports embedded content.

[coolaj86]

Tag v1.0 please. Telling people they need to install xcaddy@0 is... well, it looks bad.

v0 has no guarantees.

v1 has guarantees.

v2 and plenty of other numbers are available if those guarantees need to be broken.

🙇‍♂️

[coolaj86]

adding an embed feature before 1.0

That can wait for v1.1. New features are not-breaking and therefore valid for minor releases.

[mholt]

I forgot about this issue 😆

We can probably tag 1.0... breaking changes are just inconvenient for people. Most people use this as a CLI and not a library so a v2 is just more annoying since they'll download the latest and it'll work different, rather than a Go lib that locks in the major version. So I just wanted to minimize pain points.

[coolaj86]

Adding a feature to a CLI is non-semver breaking. New flags, new subcommands, no problem.

The main point of versioning an CLI is that you can count on the flags and subcommands that you use to be available in your local scripts as well as ci build process.

So whether or not the embed feature is here now it won't break anything to add it later.

#amiright?

[francislavoie]

True, it wouldn't be breaking, but it does feel nicer to tag 1.0 when "feature complete".

[coolaj86]

Documenting webi xcaddy@1 is easy and it will work even when v2 comes out.

Documenting webi xcaddy@0 is worrisome and unreliable.

Feature complete never happens except for very small projects (and rarely at that). This has already surpassed the ability to become feature complete. Stable is better than complete.