Consider whether this is a good interlude for a v2.0.0 release

[alerque]

I just had a look at our current ChangeLog vs. open issues vs. the in-progress PR list. I believe this might be a good interlude to tag a v2.0.0 release.

1. Lots have things have changed but the vast majority of them are related to the build and install process. This will mostly affect packages and people's hard coded "bootstrap" habits. The latter is already broken without a fix until we release, and the former I believe is pretty ship shape. Only a release and packaging cycle will tell us for sure.

2. There are quite a few small bugs fixed, a few small ergonomics improvements, much better completions, etc. These are all things that should be in people's hands but shouldn't be disruptive to switch to.

3. Nothing substantial has changed about the function of the script itself. This seems like a good way to keep this particular release cycle. There shouldn't be any reason to be skeptical of the new version once the hump of packaging changes is overcome. Nothing requires config updates, nothing is deprecated, nothing substantially refactored that would break anybodies existing usage.

4. There are certainly good improvements in the works, but nothing so immanent that it can't wait for later minor version releases (for which I hope to bring the cadence up just a touch), and quite a few of them could involve end user migrations such as moving where configs are stored, configuring aliases, etc. While we'll work to make those changes as painless as possible, having them in their own release where people can concentrate on their usage without the distraction of packaging/deployment changes seems to make sense to me?

Any thoughts @RichiH?

---

Documenting for reference:

Release procedure (as tested with this mock-up v1.9.1 release on my fork) is currently:

• Edit the changelog to change the unreleased header to a release date and add a single bullet point with exactly the phrase:

  	* Release $VERSION

  ($VERSION is the semver without a v prefix), sample commit

• Tag the release (this time with a v prefix)

• Push to main, including --follow-tags.

• Eat cake.

[alerque]

I'll be happy to do the honors when the time comes, but at least your thoughts on this process would be good. Also if you'd rather cut the cake that won't bother me either.

Either way the next step would be to get packaging updates where we can. I have Arch Linux package updates ready to go (and am hopeful that in about 2 weeks I'll be able to move it from the user contribution based AUR to the enabled-by-default [community] repository). Debian packaging looks like is in your court all they way. After that there is a long tail of places we can contact or submit updates.

[RichiH]

I have been thinking about cutting a 2.0 last week and meant to poke you about that. Given that, I think we agree :)

The one thing which I think should be closed is #295 given that GitHub & GitLab default to main branch these days.

I think the RC needs to sit & bake for some time to see if anyone manages to break it, but I am not too particular on who actually cuts it in the end as long as it's well-coordinated. If you want the honors, no problem.

[RichiH]

Let's try if the checklist works from comments in thread as well:

• Make remote branch finding more robust #295
• POSIX strict mode #303

[alerque]

The checklist formatting works but it doesn't show the issue progress bar. I'll move those to the original issue, and feel free to keep editing there.

Actually, lets just make a milestone out of it, then we can control it from the issues themselves.

---

In light of how badly broken push/pull was without our catching it, I have to wonder if we should work on overhauling #220 too...

[RichiH]

We probably should look at #220 as well, yes. We should also cut a RC ~now to increase overall test coverage & eyes.

[alerque]

Lets get the two small bugs we have known fixes for fixed before we do an RC. I don't like "release candidates" that aren't actually potential candidates. 😉

But yes a v2.0.0-rc.1 tag is in our future.

[alerque]

v2 incoming.

[alerque]

Done.

As cake to go along with this release, VCSH is now in the official Arch Linux repositories.

As a tip to other distro packagers, the PKGBUILD is here. Download and extract tarball, configure, to taste, make install.