OLD DRAFT **Intended for pre-DistroAV-rebrand 6.0.0** but now deprecated by `6.0.0_actual` rebranded branch; keep and resolve diffs before `6.0.0_actual` release

[paulpv]

• Tweak libndi-get.sh
• Tweak CMakeLists.txt
• Tweak readme
• Bump OBS-NDI version to 6.0.0
• Rebrand from Stéphane Lepin [email protected] to OBS-NDI Project [email protected]
• Add Discord link in app
• Major cleanup of strings
• Update to NDI SDK 6.0.1
• Update Config logic to match obs-websocket
• Add a --obs-ndi-verbose command-line option to print out 'a' and 'v' for audio and video packets respectively

[RayneYoruka]

Looking good so far, the readme is well documented too, it should make it much faster for people to fix issues before filling a report here or in the discord server

[paulpv]

I do wonder if the readme is too long and if the readme should just be a simple intro and we should have separate wiki pages for specific topics such as installing, troubleshooting, building, etc.

[paulpv]

FYI, I have enabled a wiki that is publicly editable (since that is the naive point of wikis) to see how that goes. I'll look into prepopulating it with some context. This way I think it can also be decoupled from having to make readme documentation changes via Pull Requests.

[RayneYoruka]

I do wonder if the readme is too long and if the readme should just be a simple intro and we should have separate wiki pages for specific topics such as installing, troubleshooting, building, etc.

I don't think it's too long, it's best to have it documented than not having any documentation at all

[Trouffman]

Should we push the NDI v6 lib as part of this develop to 4.14 release with whatever is already working and keep the other improvements for subsequent version?

[paulpv]

Should we push the NDI v6 lib as part of this develop to 4.14 release with whatever is already working and keep the other improvements for subsequent version?

I plan to do this directly in master... soon.

[paulpv]

Ready for review. There are still a few things I wanted to do to the code, but I want to get NDI6 support out first. NOTE: I HAVE NOT YET ACTUALLY TESTED THAT THIS WORKS ON ALL PLATFORMS!!! 🙂

[paulpv]

For anyone reviewing this: I think we are fine here, but just to be safe, please look out for any master code that I might have unintentionally reverted in this PR (ex: due to a possible merge mistake). The only one that comes to mind is https://github.com/obs-ndi/obs-ndi/pull/954/files, but that looks fine to me in this PR, but I just wanted to be sure I didn't accidentally miss or revert anything. This is a little complicated (but actual usual coding IMO) because some things on master I have already improved on this develop branch, but it is possible some more recent desired changes on master might have been reverted in this branch...ie possible logical conflicts.

I am 100% aware that this PR is non-trivial (I hesitate to call it "large"; I have seen some crazy large PRs way bigger than this) and there is a reason why PRs should be small.

Sorry for the below "rant"...

I also am not a big fan of the branching strategy used here that is probably all my fault. Almost everyone opening PRs targets the default master branch (understandably because that is the default branch). That complicates things when another branch, develop, is intended to be the leading edge next release. This requires the usual day-to-day task of merging master back into develop. This is not a big problem, but does open up the possibility of accidentally reverting changes on master if they conflict with similar changes on develop.

My main gripe about our branching is that I am of the personal understanding/camp/belief/religion that everything on our master branch should be [reasonably] immediately ready for release. That may sound a little odd/backwards/misguided to many people smarter than me, but let me explain.

For the record, I work at a company that does the opposite: our master is leading edge code that may not be ready for release; when it finally is ready for release we create a release branch and then increment the master version number to the next release version number; we only ever release a build from the release branch.

1. master = 1.2.0
2. create 1.2.0 release branch
3. increment master to 1.3.0

if 1.2.0 needs a patch, branch a 1.2.1 release branch from 1.2.0 and work and release that. This seems similar to how OBS does it: https://github.com/obsproject/obs-studio/branches/all

My understanding of how many Open Source projects on GitHub work (but perhaps not OBS Studio) that get lots of contributors is that most of them only ever release from master. In fact, GitHub calls this GitHub Flow: https://docs.github.com/en/get-started/using-github/github-flow

1. fork repo
2. on fork, branch feature from master
3. work feature
4. open PR to upstream master
5. merge fork feature to upstream master
6. This process repeats until eventually a release tag is created and a release is built and released Simple (but rarely are things always that simple)

This tells me that master should always be in a shippable state. (Maybe there is a [not so] subtle difference between "should always be in a shippable state" and "should always be [reasonably] immediately ready for release"...the latter implies that all version numbers defined in the code are set/incremented correctly)

What this does not tell me or the uninformed reader/developer is how to actually release. When a feature PR is merged to master, that contributor most likely did not increment in their branch any version number defined in the code on master. So now the master still says it is the old version (ex: 1.2.3), but now it has new code in it and is still the old version number. So now the version number on master needs to be incremented. So now you [should] need to create a feature branch from master to increment the version number to 1.2.4 and then merge that back to master and THEN you can release the code. I personally find this unintuitive, highly confusing, and non-ideal. My understanding is that this is how most simple Open Source projects on GitHub work. I would be wrong.

Speaking of I could be wrong, I think that is how the OBS-NDI repo has historically worked before I got involved.

When I started to get involved I unfortunately approached using this repo with a type of GitFlow mindset.

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
• https://nvie.com/posts/a-arguably-successful-for-some-git-branching-model/ ;)
• https://medium.com/android-news/gitflow-with-github-c675aa4f606a

Simplified:

1. branch develop from master
2. branch feature1 from develop
3. work feature1
4. merge feature1 to develop
5. branch feature2 from develop
6. work feature2
7. merge feature2 to develop
8. prep develop for release
9. merge develop to master
10. release master

I am not going to get into any [religious] arguments about the pros or cons of GitFlow, I am just saying factually that I did try, right or wrong, to start using it in the OBS-NDI repo...and I kind-of regret that.

I now believe that GitFlow does not work very well in an Open Source project where most code contributors don't know to follow GitFlow. GitFlow would only work if everyone follows it, like at a small team at a company where everyone understands their Way Of Work and there are no outside contributors. If someone on a GitFlow team starts branching feature PRs from master (instead of develop) and merging them to master (instead of develop) then that entirely breaks GitFlow.

One way to mitigate this in an Open Source project might be to make the develop branch the default branch, but that might still confuse people; human nature seems to be that most non-professional developers instinctively just want to branch from master by default and may even intentionally go out of their way to change their PR from [the default] develop back to master. I thought there once was a repo setting that allowed you to enforce GitFlow and define your branches, but I don't see that anymore.

People are going to be people. People are going to ignore GitFlow.

So, this is a big long rant to say that I am open to future healthy constructive conversations about a better git branching/releasing strategy for OBS-NDI, but unless I hear any better ideas I am going to stop using a develop branch and go back to using a basic GitHub Flow with its awkward [to me, unless I am probably missing something obvious] release steps.

Perhaps we may eventually go to a more OBS-Studio type of flow (and what I also use at work) of also having a release branch (RB), and when that RB is created then the master is incremented to the next version that will be eventually be released in the future.

Apologies again for the rant! :)

[Trouffman]

Tbh, if we want ppl to submit to a specific branch we have to really make it clear. Example, even myself though that you were using the develop branch mostly for you, so contribution were sometimes sent to master instead.

I have no specific preference, as long as it is clear / documented on how to contribute.

[Trouffman]

Some update : After reading through the changes support and suggestion.

I believe we should keep master for : whatever is the latest OFFICIAL tagged release. And push dev PR to the develop branch as initially expected. (to-do ; document in the dev wiki)

The main reasons are : -> the github default repo Page will ALWAYS have the latest stable infos (Important! as this is what people will see first, and if we have a "massive" rework then, this can be done "easy peasy" in the develop branch without impacting regular (non dev/contrib) users.

Other main argument :

• we refer to the install script directly from the repo (master branch) > If this was to change based on the "flavor of the moment", then that would be a pain.

And YES there might be time where we might have to update master branch even if this is not a full release. But this is an extrem use-case.

[paulpv]

@Trouffman please review my recent translation updates. Thanks

[Jaybonaut]

This would have been nice if it was released for the rename

[paulpv]

Update on this: I am aware [trust me, very aware] that this PR... my own... has been open since 2024/01/10. I want to get this version released too; I dare say more than anyone else! :)

A lot has happened since Jan: a little bit personal/work related, but mostly talking about this plugin in general.

It mostly all started 2024/02 when our Apple Developer account did not auto renew.

The Apple Developer account is only needed when signing official releases, so I never noticed this while I was working on this 6.0.0 branch.

I first noticed the expired account on 2024/04/28 when I was trying to release a https://github.com/DistroAV/DistroAV/releases/tag/4.13.2 hotfix.

@Palakis and I looked into how this open source project could qualify for an Apple Developer fee waiver:
https://developer.apple.com/support/fee-waiver/

Requirements To be eligible, you must:

• Be a legal entity with a status as a nonprofit organization1, accredited educational institution2, or government entity;
• Not be an individual, sole proprietor, or single-person business;
• Not have signed the Paid Applications Agreement (Schedules 2 and 3 of the Developer Program License Agreement) to offer paid apps or in-app purchases through the App Store (or have terminated the Paid Applications Agreement if you signed it previously); and
• Not otherwise sell digital goods or services through any of your apps. In addition, if you operate an alternative app marketplace on iOS in the European Union (EU), you may only distribute apps from developers who have also received this same fee waiver.

So that same day, 2024/04/28, I started the process of forming a OBS-NDI PROJECT non-profit [company].

On 2024/05/01 @tt2468 was generous to donate the money to pay for an Apple Developer account to buy us another year.

On 2024/05/10 the obsproject.com reached out to us because they heard that I was forming a non-profit with the name "OBS" in it, and they politely asked us to rename not just our non-profit, but they want every "OBS*" plugin to rename themself.

That is when things spiraled out of control, and I won't go into too much more detail.

Point is, this project is far from dead and I am still actively working on it.

If you have read this far and use this plugin and would like to help us out, please consider making a donation at https://opencollective.com/distroav so that we can cover the cost of regular expenses.

Stream on!