Replies: 2 comments 17 replies
-
|
To my knowledge there is no checklist so to speak, but there is that project, Version 2.4, for the 2.4 release. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe instead of hotfixing release is better to create new one adding 1 to patch number? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's an alternative approach. The downside would be that we would have to be somewhat more careful about when to commit big changes. Let's take an example. Say we've done a whole bunch of testing and bug-fixing to get the 2.4 release done and out the door. Maybe a few weeks or a few months later we then want to do a 2.4.1 release with updated translations (as has been done in the past, because it takes a while to get the translations done). If there were no other major commits since 2.4, then, as you say, we just declare the current version of master as the new 2.4.1 release and we're done. But, if someone checked in some major change after the 2.4 release, then that's going to end up in the 2.4.1 release. In that case, the 2.4.1 release would no longer be "just some updated translations for 2.4", and it might well be missing translations required by whatever the post-2.4 major change was. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, it can be a problem. One solution can be not accept pull requests on large commits for some time after release. It can work if translation is updated in some reasonable time. So it happens only at release time and not always as in gitflow. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, have used feature flags in the past when doing web development. They were useful where we wanted to do frequent releases and want to commit new code without enabling it in "production" until it was complete and tested. But it did get tricky for work that involved significant refactoring or touching a lot of code. I'm not against just doing tag releases from a single master/trunk branch (which I think are akin to Trunk-based Development, as described in this article https://www.toptal.com/software/trunk-based-development-git-flow), just as long as everyone is signed up to the consequences of it. I guess @mikfire would know more about the translations in particular. |
Beta Was this translation helpful? Give feedback.
-
|
What I remember is this. The translations were put off into their own because they take a lot of time. Even though the strings don't change much from release to release, it is still tedious work. As a rule, open source projects aren't good at the tedious work. The idea was we would release a new version (2.4.0) without waiting for every language to finish. Once the translations were done, we would release a minor update (2.4.1) with the updated translations. If I were to vote on this, I might vote to keep it as is. Yes, it is slightly more work on our part. The theory is that after we released 2.4, there would be a 2.4.1, 2.4.2, ... release as we found and fixed bugs. It is difficult to convince people to upgrade from 2.4.0 to 2.4.0. By doing the hard branch instead of a tag, we can be certain that whatever mess I've made of develop this week won't impact our ability to ship bug fixes. |
Beta Was this translation helpful? Give feedback.
-
|
No. I do not own a mac. I am quite confident it was not cross-compiled, but I have no idea who actually built the mac package. I was not really involved in the release process and I bungled the hand off from rocketman. I actually have most of the build repos up to date and have recently rolled a proper set of .deb and .rpm packages. I think I can do a .exe, but I am less confident of that. |
Beta Was this translation helpful? Give feedback.
-
|
Aha, I remembered wrong then. I can look into cross-compiling for Mac and see what I can figure out. |
Beta Was this translation helpful? Give feedback.
-
|
Worst case we could get the release out on Windows and Linux and add the Mac build later, either when we've got cross-compilation working or when someone with a Mac is available. |
Beta Was this translation helpful? Give feedback.
-
|
There is mac vm in Github Actions, so we don't need to cross-compile it, just add new pipeline in CI and grab ready distrib. |
Beta Was this translation helpful? Give feedback.
-
Do we have a checklist of things we need to do to get the 2.4 release out the door? I'd be happy to help get this done, but I'm not sure what specific things to tackle.
Beta Was this translation helpful? Give feedback.
All reactions