v1.0.0 Release Tracking Issue

[CosmicHorrorDev]

Adding some extra context to the issues on the v1.0.0 milestone. After all of those issues are resolved we should be more-or-less prepared to cut the next major release

Overall there are a lot of duplicate issues in the tracker, but I want to keep the duplicates open for the time being since many of them are old, and there's no telling how many people are already subscribed to them

Prebuilt artifacts

Quite a few people want pre-built artifacts for different platforms. Some of these are already resolved and would be fixed by just publishing the next release. Overall we want

• MacOS x64 & ARM64
• Linux x64 gnu, x64 musl, arm-unknown-linux-gnueabihf, and aarch-unknown-linux-gnu?
• Windows x64

Misc related issues

• Typo in assets names #81
• No more Windows builds? #97
• Pre-compiled Linux asset: unexpected contents #82
• arm builds for raspberry pi? #145
• builds artifacts for linux arm64 #152
• binary sd-v0.7.6-x86_64-unknown-linux-musl is not compiled against musl in releases  #153

I also know that aarch64-apple-darwin was failing to test in #179. I've run into the same issue in another project, but the executable itself was fine. It just fails on a bad CPU type in the conditions that are used to build the executable for some reason 🤷

Documentation

• Replace with a literal dollar symbol followed by another character #129
  • A literal $ in the regex needs to be escaped as $$. This should be documented in the help text and/or man page. We can probably look to rg for inspiration here
• Bug: man page and --help are not consistent #134
  • Should be an easy fix. I don't think the --help text needs to include everything that's in the man page since it's common for man pages to include more information

Misc changes

• Bug in replace? Text is removed #44
• Include contents of gen in prebuilt releases

[dev-ardi]

Should we really release 1.0? I feel like there's a lot of functionality that's relatively easy to implement before, and being 1.0 kind of suggests stability.

What about this plan:

1. Release 0.8: There have been a lot of features in the last 3 years and it will give some life to this
2. Release 0.9: Merge all of the pending PRs
3. Release 0.10:, Add more low hanging fruit functionalities, solve feature requests, etc.
4. Release [0.11..] This repo seems to have a lot more life recently, this seems like a good time to add and break stuff.
5. Release 1.0 If Any plan to publish as a library crate? #194 ends up going forward we will want to delay 1.0 as much as possible. If there are a lot of changes the public API will change a lot too.

[nc7s]

Should we really release 1.0? I feel like there's a lot of functionality that's relatively easy to implement before, and being 1.0 kind of suggests stability.

I have a bizarre case that would benefit greatly from a 1.0: #200. It would also benefit greatly if the go-for-1.0 development cycle goes rather efficiently and smoothly.

[dev-ardi]

Huh that's interesting. I'm not familiar with the epoch, is it something that will always stay there and be annoying? Can it be a temporary thing?

[nc7s]

Huh that's interesting. I'm not familiar with the epoch, is it something that will always stay there and be annoying? Can it be a temporary thing?

Once it's there it's there. It can't go away even if you (request to) remove it and package again, because it's a part of the version, and versions, obviously, go up monotonically in the archive.

[dev-ardi]

In that case I agree with releasing 1.0 as soon as possible.

This being a binary means that as long as changes are backwards compatible any change is non breaking. What's left to do? #170 seems like a wontfix

[CosmicHorrorDev]

I've gone ahead and updated the top comment on the two remaining blockers. They're #44 which I want to get fixed before release since it's a breaking change in what we expect for replacement strings, and then bundling the contents of gen (shell completions and the man page) into the prebuilt releases that get published

Currently my plan is:

• Finish the above two blockers (Already in progress. Should be done today)
• Publish an alpha release
• Make sure the alpha release works fine on the systems I have access to (ARM & x64 linux, x64 windows, x86 mac)
• Update the changelog
• Publish a beta
• Try to get some testing for the beta for around a month or so? (can we get the package included in different distros testing repos or something?)
• Publish the official release

[CosmicHorrorDev]

Getting #44 sorted out took a bit longer than originally expected, but that's the last blocker done, so we're finally ready to try cutting a release. That being said it is holiday weekend for me (and I love the spooky season), so I don't expect too much to get done before next week 👻 🎃

[CosmicHorrorDev]

Looks like all of the release assets were built and uploaded fine

https://github.com/chmln/sd/releases/tag/1.0.0-pre-alpha.5

---

Seems like a good time for a checkin.

Hi @chmln! Things are finally mostly wrapped up for a new release (aside from the task list above). Feel free to make sure that everything looks up to your standards

Assuming that everything is fine, we can probably push out a release next week. I don't have publishing permissions for crates.io, but I think we can skip publishing any of the pre-release versions there

[chmln]

Everything looks good @CosmicHorrorDev, excellent work!
Let me know what email you use for crates.io and I will add you there as an owner as well.

Sidenote: I also encourage a v1 release since the core functionality seems unlikely to undergo breaking changes

[jbicha]

version 0.8 is just as fine for Debian as 1.0 is.

[CosmicHorrorDev]

Thanks @chmln! I just updated my email for crates to be CosmicHorrorDev@pm.me (same as the one on my GitHub profile now)

---

@nc7s can we get confirmation about potential issues, or lack there of, with using v0.8 instead of v1.0?

[nc7s]

@jbicha there's an old unrelated sd that went up to 0.74. I assume a 0.8 is still lower than that hence doesn't stop violating policy?

@CosmicHorrorDev there's not really an (imminent) issue, the bug report is there for months. It's just me feeling not great about leaving a bug report open for so long ;)

[jbicha]

@jbicha there's an old unrelated sd that went up to 0.74. I assume a 0.8 is still lower than that hence doesn't stop violating policy?

I forgot that version number sorting works differently. 0.80 should be sufficient then. Just have to remember to not accidentally do a 0.9 release. We need two digits after the 0.

[dev-ardi]

It would be weird to upgrade from 0.7 to 0.80 just because of the Debian needs. I think it's more manageable to go for the 1.0 especially since this is a binary and breaking changes are unlikely.

If #194 Were to come about then we would need to be more careful but that's not yet the case.

[CosmicHorrorDev]

If #194 Were to come about then we would need to be more careful but that's not yet the case.

I haven't gotten around to reviewing that PR yet, but I don't view that as being an issue with having our next release be v1.0 only because I'm not planning on having sd released as a bin+lib crate. If the internals get published as a library then it would be done in a separate crate (something like sd-core, sd-lib, etc.)