Subsurface-mobile 2.0.1 and Subsurface 4.7.5

[Lubomir I. Ivanov]

On 7 December 2017 at 19:34, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>
>> On Dec 7, 2017, at 11:23, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>
>> how can i help with the release notes?
>
> I need to write a release announcement. I haven’t had enough time this morning to look into this - I’ve been fighting with screen shots for the iOS app for two hours. What fun.
>
>> isn't what's in our CHANGELOG.md sufficient? i know about at least a
>> couple of changes that were not mentioned there.
>
> That’s part of it - make sure all relevant changes are mentioned.

ok, i will now go through the commits and see what is missing and add
it. question about RleaseNotes.txt format bellow.
we should require PRs to always add notes to CHANGELOG.md before
accepting the PR.

> Sort them for what’s relevant to mobile vs desktop
> And then... do we want to collate them back into ReleaseNotes.txt when we do a release?
>

i'm not sure TBH. i would move what has accumulated in CHANGELOG.md to
ReleaseNotes.txt.
normally projects only have a CHENGELOG.md file, but we are using
asciidoc/a2x for the .txt.

so in our case we need an extra step.

i think the formatting of ReleaseNotes.txt has to be changed from:
"Some of the changes since _Subsurface_ 4.7.4"
...

to (the old format):
"New in version 4.7.5" / : "Changes in 4.7.5"
...

makes it easier to follow and handles a case where a version is skipped.

>> should we just copy that to a new section near the top of ReleaseNotes.txt?
>> given we have the "Some of the changes since" formatting in there i'm
>> not sure how to proceed.
>
> For Subsurface-mobile 2.0.1 it’s complicated, but for 4.7.5 it should be just that section.
>>
>> also i just merged a change from Robert.
>> should we consider an email from you like the above as the actual
>> master branch LOCK until the next release happens?
>>
>
> Yes, that would have been nice. I think the builds that I have will work for the release, but it would have been nice to not merge things without an approval from me while I’m in the middle of doing a release.
> 95% of the time others merging things is really making my life easier. There are a few exceptions.
> - don’t merge things unless you are super certain that this is the right thing or unless other maintainers have approved (this has lead to one revert recently)
> - please don’t merge things that clearly fall into someone else’s area of expertise without their feedback (I try not to touch the planner / deco calculation without Robert commenting - or Windows internals without you commenting - or core data structures without a comment from Linus, etc.)
> - when I start talking about getting ready for a release (which I usually do about a week before I think I’ll be making the release), SLOW DOWN. Pay attention to new strings and alert me to new strings, ideally right away so we give the translators a chance. Don’t merge changes that change the UI without talking to me. And usually, also check with Willem on that in case we need new screen shots.
> - if something breaks a build and you merge it, then please fix it (I’ve done that, so I’m adding it explicitly)
>

understood - that's what i said last time, but still merged things. ugh.
perhaps "the merge window is now closed" notification would make it
more clear to everyone.

one problem he have is that not all collaborators review and small PRs
tend to collect dust.
always a couple of people reviewing a PR, one being a maintainer is of
course the ideal scenario, but we only have that something like 30% of
the time.

maybe we should always wait for a couple of people approving a PR.

lubomir
--