1.1 Release: Stabilisation and Branching

[cme]

Hello lovely contributors!

Features that are planned for the 1.1 release are nearing completion. In order to allow time for stabilisation, testing and translation, while still allowing ongoing development for features intended for 1.2 and beyond, we'll be creating a development branch for this, and reserving master for 1.1-related work.

Once stabilised for release, a release/1.1 branch will be created, and development merged back to master.

                                    .-> release/1.1
                                    |
master -+--> master: work for 1.1 --+-*-> master: 1.2 onward
        |                           |
        '--> development for 1.2+ --'

Keeping the default branch for 1.1 (rather than creating the release branch immediately) emphasises that this is where we want to focus effort on testing and translation until we reach a release candidate.

During stabilisation, commits on master may be periodically merged to development to minimise the pain of the final merge from development back to master.

String Freeze

Sometime soon during the release stabilisation, we will call a String Freeze and update translations from source to allow translators to work from a stable set of strings. This will only apply to master.

Pull Requests

During the stabilisation period, any pull requests should be opened against the appropriate base branch:

• master only for fixes, translations and finalising features for 1.1.
• development for everything else.

(The base branch for existing PRs can also be changed)

Thank you, and rock on!

[trebmuh]

Nice to read! Thanks for taking the time to write it down.

I'll be out of the web from next Saturday (the 20th) to the 8th of march. Can you please confirm that I'll be able to update the French translation after this?

[cme]

Yes, absolutely.

[oddtime]

Thanks!
About the strings, I find that "Export Song" could be clearer as "Export Audio" or something similar. What do you think?
Another string has been recently modified ("copy" into "duplicate", for patterns), the rest is ok for me.

[trebmuh]

About the strings, I find that "Export Song" could be clearer as "Export Audio" or something similar. What do you think?

If that would be "export audio", how can one know if that would export a song or a pattern?

[oddtime]

Both "song" and "audio" can be written if you prefer. I wouldn't have thought I could export a pattern from there.
Of course that string can remain the same, it is not a big problem, but we have "export midi file", "export lilypond file": I don't see why we shouldn't have "export audio file" as well but a generic "export song" string for that.
I initialy thought it was for a special format different from audio.

[theGreatWhiteShark]

("copy" into "duplicate", for patterns)

Didn't you already change this via a PR?

[oddtime]

Didn't you already change this via a PR?

yes! ;)

[trebmuh]

Of course that string can remain the same, it is not a big problem, but we have "export midi file", "export lilypond file": I don't see why we shouldn't have "export audio file" as well but a generic "export song" string for that.

That sounds good to me.

[theGreatWhiteShark]

I might be derailing here. But picking up the "Export Song" string I wonder if this still works the way a user would expect with all the changes done for 1.1.

In previous versions exporting a song could only mean to, well, export the whole song. But now we can mark, copy, and paste individual parts of the song. Would the user expect/hope to export only the select parts? When implementing this it would also eliminate the need to make a separate option for exporting a pattern (as audio, midi, lilypond). But this is only an option if it feels natural. (Why do I bring this up: when deciding to implement #1166 I would do so by creating a selection and providing the option selection to loop or punch-in/out. This might cover customized export as well. In that case "Export Song" might be changed to "Export Audio" anyway. Well, but I also don't want to promise to much stuff. Who knows how long it takes to implement all those things (or how much time I will have at hand)).

[trebmuh]

Sounds a good idea to me.

[guocheng98]

Awesome! This workflow definitely makes it easier for us translator/localizers to contribute. Thanks!
btw, I suppose there will be an official announcement saying we are entering into this stabilisation stage, right? Or it's already begun? Just to make sure when I should get the freezed string :)

[cme]

There are changes for 1.1 that haven't been merged to master yet that will bring new strings with them. When those are complete and merged we'll announce the status on the email list and a pinned announcement here.