pencil icon indicating copy to clipboard operation
pencil copied to clipboard

Published 20 hours ago • verified publisher icon pencil2d

0.7.0 Release Plan

Open chchwy opened this issue 2 months ago • 13 comments

Hey guys, it's time to release a new version.

For our next release, I like to call it v0.7.0 as we've been adding a substantial number of features and fixes.

It's also good to follow the semantic versioning, where MAJOR.MINOR.PATCH stands for BREAKING.FEATURE.FIX. The second version number gets bumped whenever we add a new feature. And third version number is for bug fixing.

For this v0.7.0 release, please carefully review the milestone: →→→ 0.7.0 milestone

While there are still a couple of unresolved issues in there, I personally prefer not to fix them in this release unless they're urgent, e.g., Wix5? Let me know what you think.

Source code

  • [ ] Bump version number (common.pri)
  • [ ] Prepare release notes for CHANGELOG
  • [ ] Make sure all unit tests are working and are OK
  • [ ] Test all features known to work and make sure they behave the same
  • [ ] Update contributor list
  • [ ] Update MetaInfo
  • [ ] Make sure 0 issues in milestone
  • [ ] Add release tag to the correct commit
  • [ ] Push to release branch

Deployment

  • [ ] When renaming the AppImage, also update the plaintext metadata block at the beginning of the *.AppImage.zsync file accordingly
  • [ ] Build and upload manually compiled versions:
    • [ ] 32-bit Linux AppImage
    • [ ] Legacy macOS (10.7-10.11)
    • [ ] Legacy Windows (Windows XP/Vista)
  • [ ] Add downloads to the Bitbucket mirror
  • [ ] Update download links:
  • [ ] Update packages

Social media

Announce with release notes (or a link to the release notes) on the following platforms:

chchwy avatar Apr 26 '24 08:04 chchwy

  • The WiX 5 PR has a small bug fix in addition to the update. Even if the update itself is not going into the release, we should at least cherry-pick the fix.
  • #1491 is an issue that seems to bite users somewhat regularly (as recently as two days ago in fact: #1828) and shouldn’t be too difficult to put at least a stop-gap solution in place, I don’t really want to release another version that has this issue.
  • #1782 actually has two likely fixes in the comments that would just need to be verified… I put it on the milestone expecting it to be done long before the release, but as it hasn’t seen activity in a while and its severity is not particularly high, we can postpone it
  • #1812 is such also such an easy fix that I don’t want to delay it any longer than necessary
  • #1813 is a rather annoying regression on Windows, I do think it would be nice to have that fixed but since @MrStevns has assigned himself I’ll let him decide

I’ll get to work on #1491 and #1812. I’ve also updated the release checklist to the latest version from the wiki.

J5lx avatar Apr 26 '24 11:04 J5lx

@J5lx you're welcome to take #1813 as I need to debug on a virtual windows machine in order to reproduce and fix the problem.

MrStevns avatar Apr 26 '24 15:04 MrStevns

It's also good to follow the semantic versioning, where MAJOR.MINOR.PATCH stands for BREAKING.FEATURE.FIX. The second version number gets bumped whenever we add a new feature. And third version number is for bug fixing.

I'm not opposed to that versioning scheme, it's definitely the standard at this point, but unless we can get everyone to change the way we organize and commit to this repository, then this is impossible. There's currently nothing separating feature changes from fix changes. I've suggested changes to this years ago, and here we are still doing it the worst way. Quite frankly I don't know if we even have the people-power to maintain more than one branch right now.

I will look over my TODO lists right away, but I have at least two small but important things I think should be in the next release (both unreported). I will try to get pull requests up as soon as I can. There were also a couple recent reports in the forums about nightly build vector issues I have not had time to review yet.

Additionally, we will need to discuss what we are doing for the macOS release. I would like to see native arm support (I have not fully decided if a universal binary or two separate downloads would be better). I think getting app notarization set up before the release is a very good idea now that I've got a developer account (maybe even an app store release?).

Finally, I'd like to propose that we make a release candidate for this. I can't recall how we've handled this previously, so forgive me if I'm suggested something we're already doing. This will give us time for a larger proportion of our users to all test the same version that will ideally become the next release and stop any major bugs from being released like in one of our previous releases. This also gives more time for creating the manual builds and preparing packages, release notes, announcements, etc.

scribblemaniac avatar Apr 28 '24 05:04 scribblemaniac

It's also good to follow the semantic versioning, where MAJOR.MINOR.PATCH stands for BREAKING.FEATURE.FIX. The second version number gets bumped whenever we add a new feature. And third version number is for bug fixing.

I'm not opposed to that versioning scheme, it's definitely the standard at this point, but unless we can get everyone to change the way we organize and commit to this repository, then this is impossible. There's currently nothing separating feature changes from fix changes. I've suggested changes to this years ago, and here we are still doing it the worst way. Quite frankly I don't know if we even have the people-power to maintain more than one branch right now.

Our current workflow can be improved by adopting release/X.Y.Z branches. Working primarily on the main branch is far from the "worst". Actually, trunk-based development has been proven to be very effective and used by high-performing teams. (ref: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)

The way to separate the feature/fix releases is to have a release branch, e.g., release/0.7.0 this time. As long as a bug is identified and we agree this fix needs to be released, simply cherry-pick the fix commit to the release/0.7.0 branch and then make a 0.7.1 release. This bugfix release will be very lightweight and won't cost too much time and effort.

Below is a random google image that shows the main idea:

Trunk based development is good for small teams and works amazingly well with my current dev team of more than 20 people. I used to be in a team that used complex Git flow and it even required a dedicated release manager to deal with branches otherwise few know the differences between branches.

I will look over my TODO lists right away, but I have at least two small but important things I think should be in the next release (both unreported). I will try to get pull requests up as soon as I can. There were also a couple recent reports in the forums about nightly build vector issues I have not had time to review yet.

Please open tickets first and put them in to the milestone so all of us can track the progress.

Additionally, we will need to discuss what we are doing for the macOS release. I would like to see native arm support (I have not fully decided if a universal binary or two separate downloads would be better). I think getting app notarization set up before the release is a very good idea now that I've got a developer account (maybe even an app store release?).

Those are very good ideas and important. But I don't see the urgency to include them in this release. Apple silicon users will be fine with Rosetta 2. arm64 and universal app will require us to move to Qt6 in the first place. Apple store release needs more investigation due to the GPL license.

Finally, I'd like to propose that we make a release candidate for this. I can't recall how we've handled this previously, so forgive me if I'm suggested something we're already doing. This will give us time for a larger proportion of our users to all test the same version that will ideally become the next release and stop any major bugs from being released like in one of our previous releases. This also gives more time for creating the manual builds and preparing packages, release notes, announcements, etc.

I thought what we learned from the past is no one downloading RC. A better way is to release 0.7.1 as soon as possible when a critical bug is found.

chchwy avatar Apr 28 '24 07:04 chchwy

Those are very good ideas and important. But I don't see the urgency to include them in this release. Apple silicon users will be fine with Rosetta 2. arm64 and universal app will require us to move to Qt6 in the first place. Apple store release needs more investigation due to the GPL license.

Afaik Qt 5.15 does support universal apps, it's just that you have to compile it yourself to use it? at least their documentation mention it but maybe that's wrong? https://doc.qt.io/qt-5/macos.html It used to be for Qt 6 only but nowadays i believe they also support it for the open source LTS.

I thought what we learned from the past is no one downloading RC. A better way is to release 0.7.1 as soon as possible when a critical bug is found.

Based on our current release track history, I do not have the confidence to say that we can release anything quickly or more often than what we've done so far. It's been more than 3 years since our last release. For us to be able to release more often we either need to severely cut down on what needs to be done in order to release, so it can be automated, or accept that releases won't happen more often than what we're doing right now.

I can't see how changing or improving our git strategy will fix this. How can we make a quick hotfix release, when we still have to do all kinds of manual work like release for legacy systems, write release notes, update packages etc...

I think we're being a bit too optimistic on that front or maybe my view is just too cynical from seeing our lack of releases, even though we've discussed it many times.

MrStevns avatar Apr 28 '24 08:04 MrStevns

Those are very good ideas and important. But I don't see the urgency to include them in this release. Apple silicon users will be fine with Rosetta 2. arm64 and universal app will require us to move to Qt6 in the first place. Apple store release needs more investigation due to the GPL license.

Afaik Qt 5.15 does support universal apps, it's just that you have to compile it yourself to use it? at least their documentation mention it but maybe that's wrong? https://doc.qt.io/qt-5/macos.html It used to be for Qt 6 only but nowadays i believe they also support it for the open source LTS.

Thanks, good to know that it's been ported back to Qt5. My previous understanding was that arm64 binary finally came with the official Qt 6.2 release. But my question remains, what's the major concern of lacking arm64/universal app that holds back this release?

I thought what we learned from the past is no one downloading RC. A better way is to release 0.7.1 as soon as possible when a critical bug is found.

Based on our current release track history, I do not have the confidence to say that we can release anything quickly or more often than what we've done so far. It's been more than 3 years since our last release. For us to be able to release more often we either need to severely cut down on what needs to be done in order to release, so it can be automated, or accept that releases won't happen more often than what we're doing right now.

You got the point. We either have to severely cut down the work or automate them. What we don't want is keeping adding more work to this 0.7.0 release until it's fully ready.

I didn't have the same confidence as you in the past 3 years because I barely had any time to do my own things after work, house chores and parenting. (15 mins each day probably) However now that my daughter has turned two years old (!) and she can sleep overnight with her brother without disturbing her parents.

I can't see how changing or improving our git strategy will fix this. How can we make a quick hotfix release, when we still have to do all kinds of manual work like release for legacy systems, write release notes, update packages etc...

Surely it does. A minimal new version leads to less QA time and a shorter release note.

WinXP is old enough, I won't object to dropping support for it. If we want it, building Windows legacy version can be automated and it's nearly done in my branch.

How about dropping the Mac legacy version as well? macOS 10.11 is really old. From my company's telemetry data, the percentage of 10.15 users is around 0.9%, 10.14 is 0.4%, 10.13 is 0.34%, and I didn't see any 10.11 users.

I think we're being a bit too optimistic on that front or maybe my view is just too cynical from seeing our lack of releases, even though we've discussed it many times.

Let me ask the question in the other way. Isn't the current master branch build way better than 0.6.6 after all these improvements and fixes over the years?

chchwy avatar Apr 28 '24 10:04 chchwy

Afaik Qt 5.15 does support universal apps, it's just that you have to compile it yourself to use it?

I’ve had untested universal builds of Qt 5.15.11 with KDE patch collection lying around since last year, and besides some packaging work and polishing of the build process (and the fact that they’re untested), I would consider that work to be mostly finished. If anyone wants to try them out, the link is on Discord.

I thought what we learned from the past is no one downloading RC. A better way is to release 0.7.1 as soon as possible when a critical bug is found.

We had RC releases exactly three times, nearly 6-7 years ago. Perhaps it’s time to give them another chance.

WinXP is old enough, I won't object to dropping support for it.

IIRC when we discussed this a while back we ended up with a proposal to make 0.7 sort of a “farewell release” to XP and Vista and drop them after that release.

J5lx avatar Apr 28 '24 10:04 J5lx

Those are very good ideas and important. But I don't see the urgency to include them in this release. Apple silicon users will be fine with Rosetta 2.

It's not urgency so much as convenience. We're already going to need to manually handle several of the release builds, and doing a little bit of extra work will result in benefits for a lot of people who use the stable release.

Apple store release needs more investigation due to the GPL license.

Yes, a good point about the App Store. I could not find a lot of information about the current state of App Store Terms/GPL compatibility, but it's probably not going to work out.

IIRC when we discussed this a while back we ended up with a proposal to make 0.7 sort of a “farewell release” to XP and Vista and drop them after that release.

Concerning the legacy build, here is the full proposal from @J5lx on Discord last year (with the already-completed points removed):

  • Immediately after the release we raise the minimum Qt version to 5.15. This will allow us to keep our macOS and Linux support as-is, but XP and Vista will no longer be supported (i.e. the Windows legacy version will be dropped). Essentially what David suggested above.
  • 5.15 will also allow us to upgrade all the way to MSVC 2019, in turn allowing us to switch to C++17 (AFAICT)
  • We will notify users of the OS support changes as soon as they are decided.
  • Going forward, we will only release a legacy build if there is someone who volunteers to actively maintain it, as described above. We should probably also agree on specific requirements for what is expected of the maintainer and write that down somewhere (TBD).

scribblemaniac avatar Apr 28 '24 19:04 scribblemaniac

@chchwy

Thanks, good to know that it's been ported back to Qt5. My previous understanding was that arm64 binary finally came with the official Qt 6.2 release. But my question remains, what's the major concern of lacking arm64/universal app that holds back this release?

I personally have none, except that it should run on x86_64 which is currently not the case until #1835 has been solved. This can either be done by introducing the addition of arm runners, or setting our existing runner explicitly macOS 12 again.

Surely it does. A minimal new version leads to less QA time and a shorter release note.

Of course that's true but then we still have 30 some boxes to tick, or do you mean that most of that can be done automatically?

I have no objection in adding release branches. Let's do it if you think it'll improve our lack of release train situation.

MrStevns avatar Apr 29 '24 06:04 MrStevns

Those are very good ideas and important. But I don't see the urgency to include them in this release. Apple silicon users will be fine with Rosetta 2.

It's not urgency so much as convenience. We're already going to need to manually handle several of the release builds, and doing a little bit of extra work will result in benefits for a lot of people who use the stable release.

If I get it correctly in this discussion, we either have to officially move to Qt6 or use an untested Qt 5.15 SDK to make the arm64 app. As I see it, we could let our users know the arm64 nightly builds are available. (it is available, right?) and decide when we want to release the Qt6 arm64 app publicly. How does that sound?

Apple store release needs more investigation due to the GPL license.

Yes, a good point about the App Store. I could not find a lot of information about the current state of App Store Terms/GPL compatibility, but it's probably not going to work out.

GPL license requires that users can access the source and freely redistribute copies of the software. Source code is easy, we could always ship the software with a copy of the source code (maybe in a zip). The redistribution problem is hard, I am not very sure what we can do.

IIRC when we discussed this a while back we ended up with a proposal to make 0.7 sort of a “farewell release” to XP and Vista and drop them after that release.

Concerning the legacy build, here is the full proposal from @J5lx on Discord last year (with the already-completed points removed):

  • Immediately after the release we raise the minimum Qt version to 5.15. This will allow us to keep our macOS and Linux support as-is, but XP and Vista will no longer be supported (i.e. the Windows legacy version will be dropped). Essentially what David suggested above.
  • 5.15 will also allow us to upgrade all the way to MSVC 2019, in turn allowing us to switch to C++17 (AFAICT)
  • We will notify users of the OS support changes as soon as they are decided.
  • Going forward, we will only release a legacy build if there is someone who volunteers to actively maintain it, as described above. We should probably also agree on specific requirements for what is expected of the maintainer and write that down somewhere (TBD).

That sounds great. so 0.7.0 will be the last version that have Win/Mac legacy build. (if there is no 0.7.1 :p)

I have another question, what about Linux 32bit build? Can we drop it or automate it? How many users are using it?

chchwy avatar Apr 29 '24 07:04 chchwy

@chchwy

Thanks, good to know that it's been ported back to Qt5. My previous understanding was that arm64 binary finally came with the official Qt 6.2 release. But my question remains, what's the major concern of lacking arm64/universal app that holds back this release?

I personally have none, except that it should run on x86_64 which is currently not the case until #1835 has been solved. This can either be done by introducing the addition of arm runners, or setting our existing runner explicitly macOS 12 again.

Thanks for looking into the issue. Let's make the arm64 nightly builds available first and arrange the public release later. No need to rush from my perspective.

Surely it does. A minimal new version leads to less QA time and a shorter release note.

Of course that's true but then we still have 30 some boxes to tick, or do you mean that most of that can be done automatically?

That's true. However, the first and foremost priority is to publish the app and make it available for downloads. The website post, social media announcements or package updates can take their time.

I have no objection in adding release branches. Let's do it if you think it'll improve our lack of release train situation.

I share the same frustration with you in lacking of releases.

I learnt that running an open-source volunteer project does not have to follow the standards of a commercial project. We always have the flexibility to make changes as needed. I can't wait to see the undo/redo implementation included in the next release.

chchwy avatar Apr 29 '24 07:04 chchwy

I thought what we learned from the past is no one downloading RC. A better way is to release 0.7.1 as soon as possible when a critical bug is found.

We had RC releases exactly three times, nearly 6-7 years ago. Perhaps it’s time to give them another chance.

It's okay to do RC again. So where should we start? Anyone have any good ideas to convince our users to test it?

chchwy avatar Apr 29 '24 07:04 chchwy