2.2 beta release

[Be-ing]

Does build/debian/changelog need to be updated for beta releases?

TODO before merging (these can be done outside of this PR):

• update build/windows/golden_environment when the new build environments finish building (Jenkins job)
• get updated macOS builder connected to Jenkins
• rebuild macOS build environment
• update build/osx/golden_environment

[esbrandt]

There was no LGTM, nonetheless the i10n changes were pushed to Transifex.

The following happened On Transifex:

• Unrelated to this PR´s commits , the settings for the github-master branch are now messed up ( the resource was changed to mixxxdi-github-master from mixxxdj-github-master , notice the typo. The strings were filled up by the translation memory, but we lost ALL string reviews. And we had nearly complete reviews with some languages. This is bad, and i do not know of an automated way to have them back. Transifex has no snapshots.

What to do on Transifex:

• Fix Transifex slug for github-master branch.
• Make this resource translatable again (currently set to read-only).
• Update Transifex slug for github-release-220 branch (see review comments).
• Investigate, how to revert the github-master branch and get the reviewed strings back.

[esbrandt]

When cutting a branch, please stick to the existing naming scheme.
Use mixxxdj.github-release-220

I do not know why it is currently mixxxdj.github-master , coming from the 2.1 branch it should be mixxxdj.github-release-210, see 5015f4d. Maybe some criss-cross merge.

[esbrandt]

Please revert. There was a bug on Lauchpad (can not find it atm) that discussed this issue, but the idea to discard translations below a certain percentage of completion was dismissed.

[Be-ing]

I did this because discarding translations with low completeness was discussed in #1610. I can change that back though.

[esbrandt]

Please revert. See above.

[Be-ing]

There was no LGTM, nonetheless the i10n changes were pushed to Transifex.

Sorry, I was not aware that review was expected before pushing to Transifex. If so, then this should be explained on the the wiki.

Unrelated to this PR´s commits , the settings for the github-master branch are now messed up ( the resource was changed to mixxxdi-github-master from mixxxdj-github-master , notice the typo.

Whoops, I was editing the settings for that resource because it was confusingly named for 2.2 although the slug said master. I just corrected the typo. Apparently I accidentally edited the slug in the process. I don't know if/how we can get the reviews back. I also don't see how to make it available for translation again.

I am questioning whether we should have a Transifex resource specifically for the master branch. I think it would be clearer to have resources only for Mixxx releases. So I propose renaming the resource for master for 2.3 now because what is currently the master Git branch will become Mixxx 2.3. Then when we branch 2.3 beta we can make a new resource for 2.4.

Update Transifex slug for github-release-220 branch (see review comments).

I think this naming convention is both verbose and confusing. It took me a minute to figure out that "github-release-210" meant "2.1.0"... which is also inaccurate because it's for 2.1.x, not just 2.1.0. Also, it will be incorrect if we don't use GitHub anymore.

[Be-ing]

Ready for merge? I rebased to resolve merge conflicts with 2.1 from the 2.1.4 release.

[rryan]

Update Transifex slug for github-release-220 branch (see review comments).

I think this naming convention is both verbose and confusing. It took me a minute to figure out that "github-release-210" meant "2.1.0"... which is also inaccurate because it's for 2.1.x, not just 2.1.0. Also, it will be incorrect if we don't use GitHub anymore.

Does changing this to mixxx2-2 mean we'll lose existing translations?

@esbrandt ?

[Be-ing]

Does changing this to mixxx2-2 mean we'll lose existing translations?

I don't think so because there was no existing resource for 2.2 on Transifex. Although it is unfortunate that reviews have been lost, looking at the new resource, many languages are close to completion. I presume that happened because of some autofilling mechanism in Transifex. IIUC there are no new translations to pull in because the resource was just created. So I think this is ready for merge? @daschuer can you take a look?

[rryan]

I don't think so because there was no existing resource for 2.2 on Transifex.

Ah ok -- LGTM then.

Does build/debian/changelog need to be updated for beta releases?

We've done it in the past, but I don't think it's necessary. The builder will automatically append a changelog entry:

mixxx/src/SConscript

Lines 1083 to 1094 in 7db928d

	# Add a changelog record for this package
	if build.build_is_debug:
	description = " * Experimental build of branch '%s' at revision %s" % (branch_name, vcs_revision)
	ubuntu_append_changelog('debian', package_name, package_version,
	description, distro=ubuntu_distro,
	author=ubuntu_signing_identity)
	else:
	description = " * New upstream release."
	ubuntu_append_changelog('debian', package_name, package_version,
	description,
	distro=ubuntu_distro,
	author=ubuntu_signing_identity)

I'm not sure why we maintain build/debian/changelog given that.

[Be-ing]

Should we remove build/debian/changelog to avoid future confusion then?

[Be-ing]

@daschuer ready for merge?

[Pegasus-RPG]

What are we doing about updating all of the dependencies in the Windows and macOS environments? Has anyone checked this list to see if newer versions exist? https://mixxx.org/wiki/doku.php/dependencies

[rryan]

What are we doing about updating all of the dependencies in the Windows and macOS environments? Has anyone checked this list to see if newer versions exist? https://mixxx.org/wiki/doku.php/dependencies

I think it's a little late for that for 2.2 -- every upgrade to the environment comes with risk. We've already "burnt in" the current environment with user testing of nightlies -- updating dependencies resets that process. Newer does not necessarily, mean better or fewer bugs!

[Be-ing]

Yeah, we've updated our biggest and I think most important dependency, Qt, to the latest version. We have also updated taglib. I am working on updating the rest, but I'm okay with pushing that back to 2.3.

[Pegasus-RPG]

I think it's a little late for that for 2.2 -- every upgrade to the environment comes with risk.

Sure, but this is also what the alpha/beta period is for. Otherwise we'd never upgrade the dependencies.

Newer does not necessarily, mean better or fewer bugs!

But it usually does. I'm willing to take the risk, but only at the beginning of the alpha/beta period. This is traditionally when we upgrade them anyway. (Besides, if a bug does crop up related to a dependency, it's hard to get support when the maintainers' first reaction is "Why are you still on that ancient version?")

[rryan]

Sure, but this is also what the alpha/beta period is for. Otherwise we'd never upgrade the dependencies.

I disagree -- by the beta we should have a stable release environment that has had months of burn in by nightly users. I upgraded us to Qt 5.10.1 in May 2018 when I prepared the 2.2.x environments. That was the time to do library upgrades, IMO. The recent taglib 1.11.1 and Qt 5.11 upgrades were to fix specific problems we identified, and even those make me feel uncomfortable this close to a release.

But it usually does.

What makes you think that? We've had instances in the past where a last-minute library upgrade caused segfaults for users. (Off the top of my head, it was soundtouch... maybe 1.6.0?)

I'm willing to take the risk, but only at the beginning of the alpha/beta period. This is traditionally when we upgrade them anyway.

Yes, this is traditionally when you try to cram a bunch of updates to our core dependencies in for no good reason, and I push back as hard as I can :P.

Keep in mind, if the release schedule we set is to be followed then the beta period is pretty short. Things should be pretty finalized by then. We don't do alphas, so maybe we should consider cutting the release branch the start of the alpha period -- which would make May 2018 the time to have done this.

(Besides, if a bug does crop up related to a dependency, it's hard to get support when the maintainers' first reaction is "Why are you still on that ancient version?")

If we find a bug that's fixed upstream then we should (carefully) consider updating based on the severity of the bug. If it's critical then yea, but if it's a minor annoyance, updating the library could introduce other critical bugs. We don't usually need the help of a maintainer to debug issues though, so I'm not too worried about this point.

[Pegasus-RPG]

I upgraded us to Qt 5.10.1 in May 2018 when I prepared the 2.2.x environments. That was the time to do library upgrades, IMO.

We don't do alphas, so maybe we should consider cutting the release branch the start of the alpha period -- which would make May 2018 the time to have done this.

Yeah, that's what we're supposed to be doing. My understanding is feature freeze = branch cut -> Library upgrades -> alpha release.

[Be-ing]

I disagree -- by the beta we should have a stable release environment that has had months of burn in by nightly users. I upgraded us to Qt 5.10.1 in May 2018 when I prepared the 2.2.x environments. That was the time to do library upgrades,

I think we should decide on a specific time in the release cycle to have build environments and servers updated by. I have proposed having this done by two weeks before the beta release to ensure it does not delay the beta release again. I'd be open to moving that earlier though (maybe 4 weeks before beta?).

We don't do alphas, so maybe we should consider cutting the release branch the start of the alpha period -- which would make May 2018 the time to have done this.

Following the confusion with this PR and the Transifex resources, I thought about discontinuing the master branch and just having branches for specific releases. So for example when we release 2.3 beta, we'd start the 2.4 branch and new features would go to the new branch until we release 2.4 beta (at which point we'd make the 2.5 branch). But that's a tangent that's not really important right now. We can discuss it more on Zulip.

If we find a bug that's fixed upstream then we should (carefully) consider updating based on the severity of the bug.

I think we should routinely update all libraries in the build environment as well as the toolchain and OS on the build servers each release (every 6 months). If we're routinely updating, we won't have such big and more likely disruptive updates. When we do not routinely update, it is easy for issues to snowball, for example how updating macOS to Qt 5.11.1 just recently required updating the Mac SDK and OS. For the sake of getting 2.2 out already, I agree that we shouldn't rush any more changes to the build environments.

My understanding is feature freeze = branch cut -> Library upgrades -> alpha release.

I'm confused where you got this idea. I don't recall anything like that sequence being discussed previously, nor do I recall alpha releases being a thing in Mixxx.

Anyway, is this ready to merge?

[Pegasus-RPG]

I think we should decide on a specific time in the release cycle to have build environments and servers updated by.

Agree.

I thought about discontinuing the master branch and just having branches for specific releases

Ooo, that's interesting. I like it. Let's discuss on Zulip after 2.2.0 beta is out.

I think we should routinely update all libraries in the build environment as well as the toolchain and OS on the build servers each release (every 6 months).

Agree.

I don't recall anything like that sequence being discussed previously, nor do I recall alpha releases being a thing in Mixxx.

Formal alphas haven't been, but just replace 'alpha' with 'beta' in my statement. As for feature freeze, it's always been the goal to cut a branch at feature freeze. That time has always seemed the most logical to me to do library upgrades as well, and when I was the sole Windows package builder, that's when I did them. (For 1.10 and 1.11 specifically.)

Anyway, is this ready to merge?

@esbrandt Are things straightened out with translations and naming now?

[Be-ing]

As for feature freeze, it's always been the goal to cut a branch at feature freeze. That time has always seemed the most logical to me to do library upgrades as well

I disagree. That makes it likely that the beta release will be delayed by issues with the build servers, as has just happened. Also, the more we spread out what needs to be done for a release, the less stressful it will be because there won't be as much to do at once. So I think we should introduce a build server freeze point before feature freeze.

[daschuer]

Sometimes a new feature or bug fixes requires build server work. Can't we prepare the build environment for master whenever a change is desired. Releasing a beta is than only a matter of use the master environment and copy it to a new one for master. I thought we had this stage already.

The stressful part is only a matter of deadlines to me. As I have original proposed we can do a nearly 6 Month beta. If we cut out the new branch just after releasing the old one. I think the shortened beta period is only a result from to much squeezed into one release lately. Ok to be fair, we had no other chance with the Qt upgrade this time.

I don't like the idea of removing master, because this is a new burden for new contributor, since master is THE git standard branch.

[Be-ing]

Discussion about changing the release process aside, is this ready for merge? Is everything okay with the translations in this PR and on Transifex?

[rryan]

Discussion about changing the release process aside, is this ready for merge? Is everything okay with the translations in this PR and on Transifex?

It seems ready to me (the beta won't be live until we announce it, it's fine for the builds to start being produced for "2.2-beta").

If we aren't doing a discrete beta release, it seems odd to have a changelog entry for 2.2.0 beta. Maybe that should just be "2.2.0 (draft)" or something.

[rryan]

Nit: this isn't really a changelog -- it's a release announcement (which it's great to have a draft of!) but the goal of the changelog is to be a succinct list of what changed.

Compare to:

* Changed: Switch to Qt 5 (better HiDPI support).
* Removed: Manual display scaling option in the preferences.
* Added: Mode switch for mixing effects (Dry/Wet and Dry+Wet) [see manual](http://link-to-manual/).
* Added: LV2 Effect Plugin support on GNU/Linux and macOS.
* Added: Option to adjust opacity of waveform beatgrid lines.
* Added: Option to adjust position of the waveform play position indicator.

It's much quicker to read a bulleted list of changes than long form text descriptions.

https://keepachangelog.com/en/1.0.0/

It'd be nice if this file were markdown so we could add formatting and links to the manual.

[Be-ing]

Good point. I changed it to a bulleted list.

[Be-ing]

I'd still like an affirmative response that everything is okay with the translations.

[rryan]

Still LGTM.

I'd still like an affirmative response that everything is okay with the translations.

@esbrandt any thoughts?

@Be-ing to unblock you could just delay the .tx/config changes until we hear from @esbrandt. The mixxx.ts file looks good to me, and as long as you generated it via the command on the wiki (lupdate src -recursive -noobsolete -extensions cpp,h,ui -ts res/translations/mixxx.ts) then nothing should go wrong.

[Be-ing]

Alright, build servers are all working now. I'll post the announcement on the forum and make a PR for the website when https://builds.renegadetech.mixxx.org/job/v2.2/job/mixxx-2.2-release/47/ finishes.

[JosepMaJAZ]

Pinging to all. Are we ready to move forward with transifex translations?

I guess that we need:

• Pull language updates from transifex. Currently there are already many changes to get.
• Verify the current state of transifex to receive .ts updates (branches ok?, naming, procedure is repeatable?,...)
• Push a new ts update to transifex for 2.2 (and 2.3).
• Coordinate better who has to:
  • pull updates from transifex
  • push updates to transifex
  • branch.
• document procedures

[rryan]

@JosepMaJAZ yes let's! I just opened #1876 which updates / pulls using the instructions.
https://www.mixxx.org/wiki/doku.php/internationalization#developers_-_i18n_l10n_and_mixxx
and
https://github.com/mixxxdj/mixxx/blob/master/build/wix/Localization/README-Translations.md

The mixxx2-2 slug seems to be working, as we got a bunch of new translations.

I think there's nothing to tx push for 2.2 -- I think there have been no string changes since this PR.