pencil icon indicating copy to clipboard operation
pencil copied to clipboard
verified publisher icon pencil2d

0.7.0 Release Plan

Open chchwy opened this issue 1 year ago • 25 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

  • [x] Make sure all unit tests are working and are OK
  • [x] Test all features known to work and make sure they behave the same
  • [ ] Update contributor list
  • [x] Update MetaInfo

    • [x] Add entry for new release

      → Update TODOs in #1845 then merge

    • [x] If the new release makes visible changes to the user interface, update the screenshot following the Flathub quality guidelines @J5lx

      → Merge pencil2d/pencil2d.github.io#32 (simultaneously with the actual release)

  • [x] Make sure 0 issues in milestone
  • [x] Add release tag to the correct commit
  • [x] Push to release branch

Deployment

  • [x] 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:
    • [x] 32-bit Linux AppImage
    • [x] Legacy macOS (10.7-10.11)
    • [ ] Legacy Windows (Windows XP/Vista)
  • [ ] Add downloads to the Bitbucket mirror
  • [x] Update download links:
  • [x] 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

I will be actively using Pencil2D in the next week and then prepare for the release if no further issue is found.

For issues remaining in the milestone:

  • #1812 won't touch the app itself and I believe it's nearly ready.
  • #1813 I will be looking into this issue if I have time. Otherwise, I will push it back to 0.7.1

edited: just found that #1812 and #1832 is one issue

chchwy avatar May 21 '24 04:05 chchwy

I was ready to say we should go ahead with the RC as soon as #1843 was merged, however now a user is reporting issues with the macOS builds (#1846), which needs to be addressed before we can make a functional release. Personally I can't reproduce the issue in my macOS Ventura VM, so I'm not going to be able to help much with that issue. I looks like it might have been caused by the removal of macdeployqt but that's just a guess. Once that is dealt with I am fully on board with proceeding to the RC.

scribblemaniac avatar Jun 06 '24 22:06 scribblemaniac

I was ready to say we should go ahead with the RC as soon as #1843 was merged, however now a user is reporting issues with the macOS builds (#1846), which needs to be addressed before we can make a functional release. Personally I can't reproduce the issue in my macOS Ventura VM, so I'm not going to be able to help much with that issue. I looks like it might have been caused by the removal of macdeployqt but that's just a guess. Once that is dealt with I am fully on board with proceeding to the RC.

I will check and see if there is an issue on Monday. My Intel mac is not with me at the moment.

chchwy avatar Jun 07 '24 00:06 chchwy

And once the mac issue is addressed, we will go ahead and release 0.7.0....without a RC. The 0.7.0 release process has been taking too long.

chchwy avatar Jun 07 '24 00:06 chchwy

While I agree this has been taking longer than it should, I strongly disagree with skipping the RC. Believe me, I'm eager for users to start using the new version. But I don't think the fact that it takes so long is a good justification for skipping steps we've already agreed upon, if anything it's all the more reason to make sure we do it right the first time so we don't have to go through making another release right away! Just imagine if you had rushed to release it a week ago without an RC: apparently the macOS release wouldn't even be working for some (most?, all?) Apple users. I find that concerning.

What harm is there in waiting an extra couple of weeks for users to try the release before it goes live? I'm confident we can get at least some of the more active users on Discord to try out the RC with an announcement, and perhaps an informal contest of some sort.

scribblemaniac avatar Jun 09 '24 07:06 scribblemaniac

Alright, considering this is a release after years, let’s make the 0.7.0 RC. I’ll build the RC version and upload it to our webpage. The release will be official after a week if no new issues are found.

I’ve verified that the x86_64 Mac app is working as expected. The macdeployqtfix isn’t relevant. Also, the arm64 app isn’t part of the scope for the v0.7.0 release.

chchwy avatar Jun 11 '24 13:06 chchwy

Branch release/0.7.0 is created. https://github.com/pencil2d/pencil/tree/release/0.7.0

chchwy avatar Jun 18 '24 16:06 chchwy

@chchwy

Hi,

The Debian package of the new 0.7.0 release was uploaded to unstable repository today. In about 5 days will migrate to testing and also should be available in Ubuntu as well soon.

fabiomt avatar Jul 13 '24 18:07 fabiomt

@chchwy

Hi,

The Debian package of the new 0.7.0 release was uploaded to unstable repository today. In about 5 days will migrate to testing and also should be available in Ubuntu as well soon.

thank you very much.

chchwy avatar Jul 14 '24 09:07 chchwy

v0.7.0 is out. https://www.pencil2d.org/download/ The blog post for the v0.7.0 release is working in progress.

chchwy avatar Jul 17 '24 02:07 chchwy

As maintainer of the Pencil2D package in Fedora, this update is on my radar, and I hope to have a chance to audit the changes and update the distribution package within the week.

musicinmybrain avatar Jul 17 '24 12:07 musicinmybrain

I managed to get to this today. Pencil2D 0.7.0 will appear in the next successful Fedora Rawhide compose, and eventually in the Fedora 41 release this fall. I did a quick interactive test with the new package, but any testing and feedback is welcome.

I’m not actually a Pencil2D user, so I’m not intimately familiar with its UI, but given that the release notes suggest this is a major update with some UI changes (and given that I switched from Qt5 to Qt6 at the same time) I have no current plans to update existing stable branches (F40, F39, EPEL9) to 0.7.0. I think this is consistent with Fedora’s Updates Policy. However, updating these branches is technically feasible if it turns out there is a good justification that outweighs the possible UI/UX disruption.

musicinmybrain avatar Jul 17 '24 20:07 musicinmybrain

I managed to get to this today. Pencil2D 0.7.0 will appear in the next successful Fedora Rawhide compose, and eventually in the Fedora 41 release this fall. I did a quick interactive test with the new package, but any testing and feedback is welcome.

I’m not actually a Pencil2D user, so I’m not intimately familiar with its UI, but given that the release notes suggest this is a major update with some UI changes (and given that I switched from Qt5 to Qt6 at the same time) I have no current plans to update existing stable branches (F40, F39, EPEL9) to 0.7.0. I think this is consistent with Fedora’s Updates Policy. However, updating these branches is technically feasible if it turns out there is a good justification that outweighs the possible UI/UX disruption.

Thank you for informing us.

chchwy avatar Jul 18 '24 05:07 chchwy