Major release should have a video/changelog on the website. 1.5 → 1.6
Small releases/bug fixes can have a section for changelog in the forum. 1.5.1, 1.5.2, etc.
But most importantly the team should be comfortable with such releases or they do longer testing or add a dedicated QA.
I would disagree with that suggestion. The list of changes (aka the changelog) - whether big or small - should always be together for easy reference by users. I would not encourage separating these out. Of course a forum or blog post could always go in more detail perhaps to expand on things, but there should still be a “single source of truth” for the changes in every version.
Wholeheartedly agree with everything said by Dean. I’m sure as a community we can all help Bricks’ development if we can maybe find a way to leverage the end users more (perhaps in a more engaged beta testing manner or by new means). There are a lot of intelligent developers in our community that want to help Bricks grow and succeed! Currently, however, new releases are extremely detrimental to workflow and inhibit Bricks’ growth from a marketing/ word of mouth perspective.
+1
In general: quality before quantity.
This is an endurance sport not a sprint.
I’m really annoyed right now. In the current quality cycle of recent releases, Bricks is not professionally usable.
Rather calmly go through the roadmap, if breaking changes are pending inform the people in advance about it (blocks were already not a communicative achievement and now the pos: relative topic), so that you can at least react.
I’m surprised by the release logic as well. I’ve never seen new features added from beta to RC in any software. I’ve also never seen a RC full of bugs. A more balanced release cycle is needed indeed (Oxygen comes to mind). Breaking changes in every new release don’t help either. Bricks team will have to take into account that Bricks is not alpha software and is now being used on a ton of sites already.
Yes! a proper release cycle is too important to make a stable product.
IMHO opinion throwing in a new feature into a hot fix release is a terrible idea. Because it doesn’t solve the tasks an RC is laid out to do: confirm that the bugs that were introduced in the beta (remember those?) have been fixed. If not RC2 and so on. Then you work on the next minor version that could introduce features.
So, PLEASE slow down with seemingly chaotic releases. If we want to build sites for clients (not only ourselves) we want to know that introducing a new element widget isn’t going to change the layout of a previous one. Cause I’d be quite mad if I found out that I had to fix 10, 15, 30 sites because all of a sudden a container worked differently and broke a layout. Or throwing in a big (major/minor?) like breakpoints into an RC release (I do not remember seeing it in the beta) and calling it ‘experimental’.
So when you finally do add grid-stuff, please, make that its own release. Thanks for listening.
I have already mentioned this before, I am not against bricks, I love bricks, it seems to me the best builder at the moment, but also with many errors at the same time. And this is due to the massive updates, it is obvious that if you publish an update with 100 “improvements” appear 50 bugs minimum, I hope that the team can make the decision to make smaller versions, example: 1.5.1.1 > 1.5.1.2 > 1.5.1.2.1 (no matter how minimal it may be, the important thing is that it is stable when updating).
PD: Currently bricks is in a difficult position, my proposal is also that please stop thinking about adding new features and go releasing small updates but only to fix problems, at the moment I think it is more important to have a 100% stable version and not have 20 new features with 15 bugs in a row…
smaller and way faster. especially when it comes to fixing bugs.
Just go Cwicly way in terms of releases.
Just to add: Please don’t use “Experiments”. Test these before releasing or don’t release them. Really don’t want to end up like elemental.
Maybe release them as a beta release or version so that we can test those specific settings.
On the release cycle I have no fixed opinion. There is no obligation to upgrade and if you do upgrade then I assume you’ve tested your sites fully. So I’m happy with current or more granular cycles. Maybe go the way of Linux and use Long Term Support releases that are solid and stable. Then use interim releases for the new stuff?
I have no problems with the experiment feature. They’re not forced on us to use as they are always behind a toggle. That’s enough of a beta tag imo.
so we now get elementor like experimental features?
@grafikundso Experimental features have been in bricks with an experimental label since 1.3.4
Really happy to see team listening and implementing the suggestions - Introducing a smaller, more frequent update cycle 
Well done Thomas. Thanks for listening to us!
I’ve always rather liked the idea of experimental toggles… They just turned out poorly in Elementor, as some will likely never make it out of experiment hell (I can’t see flex leaving for a very long time, if ever)
I think the problem with them is that the userbase gets segmented with every toggle, and this forces development into catering for every combination.
1 product in one configuration, with safe settings, on a regular, standardised release schedule sounds like heaven to me. Glad they’re going this way 
Hi how are things
I found a problem with the ICON as it loses all its CSS styles when putting a link
I also checked if I could fix it with the ICON BOX and if luckily I was able to use it as a temporary solution
Please review ICON as it loses the styles when you choose any option
Hey,
Welcome to the forums. To report an issue, please open a new topic and share all relevant information there.
I was about to also create a topic for this. This one is one year old but still relevant. I believe me and other developers would highly appreciate more stable and tested releases. It’s just annoying you can’t update in anytime without worrying what breaks on you site today…
Would you consider releasing first beta versions and then stable versions of each built? Or any other solution like internal beta testing program with a few hundreds of volunteers? It seems in a small group you can’t ever test enough scenarios to have a stable built – so without beta testing you just throw us an experiment every time instead.
I know you are quite fast in fixing those bugs but how can I as a developer orientate in that when the releases are not marked as beta/stable?
UPDATE:
One of bricks’s fellow stated this solution in FB group which it makes a lot of sense to me:
[Ivan Arnaudov]
I think the conversation should be reframed more generally in the context of versioning and feature release / bugfixes.
In my opinion, x.y versions should be reserved for feature releases, and x.y.z should be about bugfixes, and these should not be mixed.
This way it will be fairly easy to know when to hurry up and update and when to take a more conservative approach (bugfix releases are much less likely to break things).
By mixing feature releases with bugfixes, the developer creates an antagonistic relationship between the two: a user would want to update because of a bugfix, but their website might break as a result of a feature release.
This isn’t something new and groundbreaking, WP itself follows such logic.
Keep bugfix releases separate from feature releases.
Just my 2¢
I think Thomas and the team can put this together Bricks way.
This is such an important issue for all of us. For example, Xtemos team put out a patcher system for their themes, and it works wonderfully good.
Login to admin, check patches tab, any new patch available? Click apply, done!
Of course this might also break things with any update, but solves the issue like Ivan Arnaudov suggested on FB.