3.0 Release (was 2.4 Release)

[matty0ung]

We keep meaning to do a 2.4 release and never quite getting around to it. I was thinking just to make a 2.4.0 release (assuming this is straightforward!), based on current dev branch (ie bring the 2.4 branch up to date with dev and then make a release). If and when we find any problems, we can fix them in a 2.4.1 release, but in the meantime it makes it easier for people looking for an up-to-date build to get one.

But if anyone has a strong view against this, please shout out. (Eg, we could release current 2.4 branch, but I fear it's a bit old.)

[mattiasmaahl]

I vote for releasing current dev as rc.1 and collect bug reports on that before releasing the final 2.4.
How do you fell about that kind of a solution?

[matty0ung]

Yes, that sounds a good way of doing things.

[matty0ung]

Having much fun creating Linux packages. It seems like we have two completely different ways to do this - via the separate repositories (https://github.com/Brewtarget/debian-packaging and https://github.com/Brewtarget/redhat-packaging) or via CMake. I started trying to do things manually in the separate repositories, but I'm now leaning heavily towards just using CMake and retiring those other repositories as they seem like more trouble than they are worth. Of course, I may be missing something so, as ever, happy to be corrected!

Meanwhile, am tidying up the CMake stuff.

[mattiasmaahl]

We could eave the separate repos behind, although they do serve tje purpose of not mixing the package info between distros. With that I mean that debian packages have a certain structure to them and RPMs have another. As I understand it the spearate repos where created for that purpose, keeping the releases free from eachothers package settings. But I'm sure we can make CMAKE filter them out as well.

[xzfantom]

As I remember, couple years ago cmake was creating not as good builds as native commands. Maybe now situation is better.

[matty0ung]

Ah, OK, that's good to know! I'll see how far I get with doing it via CMake/CPack. If it doesn't work or isn't good enough, we'll go back to the manual methods.

[xzfantom]

There are blocks in github actions with lintian and rpmlint - it checks that packages are good or not.

[matty0ung]

OK, I have a deb package building. I haven't checked whether it works but it mostly passes lintian. (The only warning is about us not having a man page. We should write one at some point.)

I'll try to get rpms doing the write thing then will share progress. I've done quite a lot of knocking CMakeLists.txt around, but am starting to get my head around it!

[mikfire]

Given the number of features, the new management, the several rewrites of several low-level interfaces, changes to the basic data model and other things I am sure I have forgotten, have you considered marking this as bt3.0?

[mattiasmaahl]

@mikfire that maybe is a better way to go. As you say, there has been quite the advancement since the last release. 🤔😊

[matty0ung]

Sounds like a good idea to me. Let's do it! 😄 👍

[matty0ung]

OK, I've had a go at doing 3.0.0 release. Let me know what I missed... 😸