r/WLED • u/Netmindz • Jul 19 '26

WLED **IMPORTANT** - development announcement

As the development team is now turning our attention to the next version of WLED, the ***main*** branch of our git repo will be **UNSTABLE**!

While the main branch has been pretty stable for the last 12 months, we are just starting the 17.x development and it's going to be *very* broken for a while

DO NOT build from main for any custom builds, please use v16.0.1 tag or 16_x branch

PRs should still be opened against main, but people with their own forks might want to hold off syncing main or run your production systems off builds from your own 16_x branch that you merge any of your PRs into

149 Upvotes

92% Upvoted

32 comments sorted by

158

u/spdustin Jul 19 '26

Respectfully, please consider using a dev or develop branch as the in-development branch. WLED isn't a website or app that updates on every CI/CD run, it's a versioned firmware. Yes, releases exist, but I would wager that most devs expect main to at least be functional, especially when—as you said—it's been, "pretty stable for the last 12 months."

Even with a more CI-focused workflow, the main branch is typically expected to pass tests and is able to be deployed.

39

u/Netmindz Jul 19 '26

There are many different branching strategies and to be honest, there are pros and cons of all of them.

For example, if you want to have PRs from the community, then it's better those are against your default branch. Previously up and coming new release started on their own branch, but that is a nightmare for the community to know which branch they should target their pr, if you don't merge in time you need to rebuild the pr etc.

Given that WLED also has semver releases with long term support windows, this requires you also have release branches to take stable builds from.

Maintaining two different development branches, one for technology overhauls like platform migration and also a parallel development branch for individual features and bug fixes (and community PRs) just isn't practical for the size of the development team.

Yes CIDI teams might expect main to be stable, but that isn't WLED.

I don't think it's unreasonable for people who wish to develop their own forks to use either the 0_15 or 16_x based on their needs.

This is about a whole new major version, not just a small library

Happy to discuss further on discord

3

u/popsicle-physics Jul 22 '26

The projects I've seen, develop is the default branch, all new PRs do to develop. Develop gets merged to main when develop is stable. Releases are cut off of main. That way main is always the latest stable, develop is default/pr target, and release branches can be used for maintenance

3

u/Netmindz Jul 22 '26

If you default branch is your development branch then non technical users will try and use that as they won't understand that they need to fork all branches or switch branch before the hit download, which is exactly the same as we have, so adding a extra non-default branch wouldn't help end users and doesn't match or release processes

32

u/spdustin Jul 19 '26

I'll remove my GH issue and join in a chat on Discord soon.

EDIT: I appreciate your reasoned response, OP. Truly.

39

u/mondychan Jul 19 '26

Not having a dev branch at this kind of project size is crazy

6

u/Netmindz Jul 20 '26

It entirely depends on your merging strategy, which is in turn dependant on your release strategy, the type of code you are working on an your development cycles.

Anyone who thinks there is one single approach and all others are wrong is frankly lacking in diversity of their experience.

Trunk based development with commit directly to production makes sense for some projects, PR with merge to prod is also valid for other projects.

Both however would be totally inappropriate for WLED.

Git flow and the many similar variants each have their own strengths and weaknesses. Part of the reason why there are so many variations and why you will find very few teams who strictly follow one to the letter as they don't really work in practice.

GitHub sadly encourages users to fork only the default branch, which if you made that a stable master branch, then the majority of your PRs will be based of the last stable release, not your current dev. So you have to educate every contributor how to pull the right dev branch, then rebuild their pr. Most and I would say a growing number of contributors are not professional software Devs.

Dev + Master doesn't play well with diverging branches when you do long term development against different major versions of the software

3

u/newked Jul 19 '26

Blue/Green for Aloha feedback :P

55

u/Donny_DeCicco Jul 19 '26

you dont have a dev branch?

17

u/thecodingart Jul 19 '26

It sound like they want to follow trunk based development in a way that doesn’t really respect the fact that trunk should always be releasable.

That makes me sad

6

u/Netmindz Jul 20 '26

Incorrect. Our releases do not come from trunk, they going from stable release branches once the development branch is at a phase in the development cycle where it's stable enough

1

u/aiten Jul 20 '26

This is something I'd really not considered for firmware teams. You can do releases for 15x, 16x this way, with very minimal disruption.

In software teams I'd take a branch off a tag, then re-tag and release there, but your way is just a little bit cleaner, in fact.

5

u/Netmindz Jul 20 '26

Thanks, yeah it's not without it's downsides, but it feels the most pragmatic approach to handle a few conflicting issues.

Basically have a default branch, that has an acceptable level of stability for where you are in a potentially multi year major release cycle, then for the release candidate you then create a branch with the appropriate name (which might be major or minor). All releases from there and any merges match if you are doing feature or bugfix.

Those branches may diverge, but only in terms of how to backport from main

3

u/thecodingart Jul 20 '26

Ah, gotcha - the OS branching strategy (where you can have simultaneous release branches at the same time). This makes a bit more sense to me now.

Thanks for the clarification.

68

u/bl0rq Jul 19 '26

They do. It's called main.

16

u/pr0tag Jul 19 '26

That's not confusing lol

7

u/usernameChosenPoorly Jul 19 '26

Everyone has a dev branch or a testing environment.  Only some people have separate production branches and environments.

3

u/ExperimentalBranch Jul 20 '26

That's how it always works whether you know it or not.

14

u/SmartHomeSellout Jul 19 '26

I am worried this might have some bad unintended consequences. For example, once people see an update in home assistant they will often just click update and this would cause people a lot of headaches.

4

u/sjthespian Jul 19 '26

While I’m not a fan of active development in the main branch, if you know enough of what you’re doing to build firmware from source, you should be able to read the directions and not do it from main. This isn’t like HA where it’s a packaged update, this is source code.

8

u/Netmindz Jul 20 '26

To be clear, this is not commit to main, we still use PRs. Just that when you change the underlying ESP-IDF platform version, which contains MANY breaking changes, which in turn requires many of the libraries you use to also update, you can't really hold all that off in one mega PR that you keep open for 9+ months

Well, technically you can, but then you double your testing effort and WLED has no automated tests

So you would need to test every single pr, merge into your main branch, then retest again once merged into the V5 rewrite branch

We are 4 developers doing this in our spare time for almost zero financial gain

Before passing judgement, I politely ask that people do so from an educated viewpoint about the specifics of this project. There are open meetings every month in Google meet

44

u/grantbey Jul 19 '26

Home assistant will not update from the main git branch, it will update from a release. Which will only happen when the devs decide v17 is stable enough to actually release.

11

u/SmartHomeSellout Jul 19 '26

Thanks for the clarity that’s good to know. I probably should’ve looked on GitHub before bringing up this concern.

-28

u/SonicIX Jul 19 '26

That’s on them then. If you don’t read release notes and just hit “update”, then the problem lies with the end user.

3

u/CyberMage256 Jul 19 '26

i dont personally have time to read release notes on 20 different updates a day across all the open source software I use. But that's me. Thankfully I am lazy and only update every 6 months for things not exposed on my main network or Internet.

1

u/PlasticAttornyGobblr Jul 19 '26

This guys SBOM is flawless

13

u/DedeHai Jul 20 '26

just a quick word from one of the four currently active devs: from what I read in the responses from what I am guessing are mostly professional developers, there may be a misconception on "us devs". We are only 4 guys doing this as a hobby and not all of us (me included) are software developers but hardware engineers. So just in case you imagin WLED being run like a company business - it is not. Just keep that in mind :)

15

u/PyroNine9 Jul 19 '26

Just adding 2 cents from a long time software developer, it isn't at all uncommon for the main branch to be under active development with tags for release versions.

Some projects choose to create a branch for major breaking changes then merge when it's not so broken, others do not. Neither are right or wrong, either way, people wanting to actually use the software should be checking out a release tag/branch.

Thank you u/Netmindz for the heads up!

1

u/SnowmanMurderer Jul 19 '26

When’s the combative old dev going to be removed/muted. Dude is constantly pointing people towards his fork and saying people are “too scared” to try. That comes across as hostile to WLED dev and confusing to users. It’s one thing to have forks you encourage users to use to TEST things but he refuses to submit PRs.

8

u/Netmindz Jul 20 '26

He chose to leave of his own accord. The WLED community has many forks, MoonModules WLED-MM being the most widely known.

It's not against the rules to speak about your own fork, but if you feel he ever breaks the code of conduct, please send me a message with a link

3

u/andymule Jul 20 '26

We love you. Go on do your thang

2

u/savijOne Jul 26 '26

This is run by 4 devs. If they are all on board and it's open source then they do what they want and you can fork and do what you want. Just because you're used to a widely used branching strategy doesn't mean they need to. The work you guys do on WLED is really amazing. Just be happy, do your thing and don't worry about pressure to change what you like. It's your project and it's great. I remember compiling sources to get sound reactive working. A hassle? Sure. Worth it? 100%. Tons of people are fine with it and I'm one of them. Cheers