Solaar: More regular releases required

[robbat2]

As from any plans in #654 and #574, can you please issue some more regular releases, to help distributions who want to support newer hardware that was added after the 1.0.1 release without backporting or trying to decide on a good commit.

[FFY00]

That comes down to the work being done in Solaar, making a release when we dodn't have that many changes usually doesn't make much sense. We should have a new release soon.

[pfps]

I've made several changes to Solaar recently, notably to better handle pairing for nano receivers.
It would be useful to have wider testing of these changes to pairing before a new release is done.

[robbat2]

Make a rc release to get wider testing ;-)

[WhyNotHugo]

That comes down to the work being done in Solaar, making a release when we dodn't have that many changes usually doesn't make much sense. We should have a new release soon.

It makes a huge difference for anyone relying on these changes.

Ideally, releases can be done via CI (eg: GitHub Actions). It's a matter of setting up CI so that a new tag creates a new release. Making releases a no-brainier really helps making releases as often as needed.

[pfps]

Is there a good source on how to set up such CIs?

[WhyNotHugo]

Personally, I've just gone through the GitHub Actions documentation, and set up a simple workflow that pushes to PyPI and GitHub Releases. It triggers every time a tag called v* is pushed (eg: v1.1.1).

This might serve as an example. Placing the in the repository, and making sure that Actions is enabled in the project settings should suffice.

You'll also need to provide GitHub API tokens and PyPI API tokens in the project secrets page.

[pfps]

@robbat2 One thing I would like to see addressed before a new release is getting the build failures fixed - #697 and #699. Help would be appreciated. If this doesn't get fixed I fear that the packaging stuff will have to be dropped.

[pfps]

@WhyNotHugo Hmm. This looks bit more involved than I thought it would be, but I'll take a look.

[WhyNotHugo]

@pfps It does take a bit of work, but it does make life easier. Let me know if I can help around that though :)

[pfps]

@FFY00 What about doing a RC? I have a couple little changes coming but nothing else.

[pfps]

@FFY00 I think that the state of solaar is very close to being good enough for a new release. There are a few minor pull requests that should go in before a real release, but nothing major. Just about the only decision is whether to update or remove the packaging directory.
With the added support for nano receivers, it might be best to use release 1.1.0. I'm willing to do the work to get a release out in github (and in PyPI if control can be extended). I think I would first do a release candidate, partly to see how the process goes and partly to give a heads up to anyone who might want to test out the changes.
Comments?

[FFY00]

Hey, sorry for the delay. I don't really want the releases being done on a CI because I want to sign the tags.

Right now creating releases is easy, and it's not really a maintenance burden. We don't have access to the PyPI page so we don't upload there. If sometime in the future we are able to gain onership we can just setup a simple script to make a signed tag and upload the artifact to PyPI.

My main issue with new releases is that we don't want to break things and I don't have much time to spend on testing. For this reason, I feel safer in letting the patch sit on master for a few days before tagging a release.

I think that the state of solaar is very close to being good enough for a new release

Yeah, I agree.

Just about the only decision is whether to update or remove the packaging directory.

Okay, so this is my position: I don't think we should have it here. If you still want to have packaging rules and are willing to maintain them, we can create a new repo.

and in PyPI if control can be extended

I'll send an email to Daniel.

I think I would first do a release candidate, partly to see how the process goes and partly to give a heads up to anyone who might want to test out the changes.

Exactly my thoughts, I actually starting writing that before reading your whole message :D

[pfps]

Removing the packaging directory is a reasonable way to go. I don't think that they are used now as the only ones that were used were for Ubuntu/Debian and both distribution mechanisms there have their own files.
One thing that didn't happen quite right for 1.0.1 is that the tag wasn't an annotated tag. This affects git describe and maybe other things.

[FFY00]

One thing that didn't happen quite right for 1.0.1 is that the tag wasn't an annotated tag. This affects git describe and maybe other things.

I'll add a release script to prevent this from happening in the future. Since we are going for GPG signed tags, could you send me your key ID via email? If you don't have one, and you want to make releases, please create :D

[FFY00]

@pfps shall we just do the RC now? Or do you have anything planned?

[pfps]

Just the change to unpair that's already a PR. I'll put in a PR to bring the ChangeLog up to date.

[FFY00]

@pfps is the changelog up-to-date now? If so I'll go ahead and do the release.

[pfps]

The changelog is good. The recent PR for missing firmware information is too small to note, I think. The only thing to change is the put the release tag on the first line instead of the date and commit ID.

[pfps]

It probably is a good idea to merge in my second PR for missing firmware handling.

[FFY00]

The only thing to change is the put the release tag on the first line instead of the date and commit ID.

Yes, I am aware of that.

It probably is a good idea to merge in my second PR for missing firmware handling.

Already done.

Pushing a RC release now.

[WhyNotHugo]

I don't really want the releases being done on a CI because I want to sign the tags.

Side note: you can sign tags locally, and then push them, which triggers CI. There's no conflict between these two things.

That's actually how automating releases generally works: create a tag locally, push it, and then have CI do all the release work.

[FFY00]

The current release work is just creating the release in github. There are no prebuilt binaries or anything like that that we need to provide.

I wrote a script to automate the release process, it will perform some sanity checks, create a signed tag and create the github release. This should be enough for now. Unless you think there's still something to be gained from doing it in a CI? I don't really see anything major.

[pfps]

@robbat2 There is a new release candidate for 1.0.2 and hopefully the real 1.0.2 should follow shortly. A significant change for packagers is that the packaging directory has been removed as it was becoming too hard to maintain.

[pfps]

Also, PyPI has this release candidate.

[pfps]

@robbat2 There is a new release candidate for 1.0.2 to improve icon selection. Hopefully the real 1.0.2 will follow shortly.

[robbat2]

@pfps rc3 added to Gentoo now, thanks for the heads up; rc2 was there may 11th.

[pfps]

Version 1.0.2 is just out.

We'll try to have more regular releases in the future.

[robbat2]

Thanks, merged in Gentoo now!

[pfps]

Version 1.0.3rc1 is just out.

[pfps]

Version 1.0.4rc1 is just out.
Solaar now supports HID++ devices that are connected directly via USB or Bluetooth.
Several settings have been added.
Updated translations would be useful as there are new and changed messages.

Version 1.0.4 should follow soon if there are no problems.