I’m a huge fan of the builder and every update delivers such great updates to the product - both big and small (breakpoints are done so well).
That being said, I’m concerned that each update also delivers a handful of bugs each time, and 1.5.1 delivers even more of these too.
Many of these are pretty big things that should have been caught prior to a beta and considering this is an RC, even more so. They’re not just things that belong to the new features, but are bugs that affect the existing features and break layouts, not just workflow.
Bugs I ran into on my 3 minutes of 1.5.1:
The padding/margin is gone until you open up the elements css in the layout panel
Styling was no longer applied to icons in icon list
Background overlay now overlaps content
Inherited values on typography in theme styles were showing the wrong values
This was just in a couple of minutes of testing.
Other bugs I noticed in 1.5:
Typography constantly gets reset or applied to other classes when switching breakpoints
Icon list icons shrinking because they don’t have flex-shrink: 0 applied
Mobile burger icon is offset because you need to apply line height: 0
Mobile burger icon does some weird floating animation when tapped on mobile (seems like it’s moving to a different position in it’s highlighted active state)
Border-bottom isn’t showing in builder if set on a display: inline element
Element shows inherited value of display: block in builder, even if set to display: inline on base breakpoint
Now, of course, saying “don’t introduce bugs” isn’t helpful, and I know it’s the last thing the team wants in the first place.
So I wanted to put this post out not just to express my concern, but to see if there are any plans in place to help with making these releases more stable?
Some ideas that came to mind:
Smaller releases, more often (even just to get bugs fixed - like 1.5.1.1 etc) - look at Cwicly’s changelog for example. These do releases with just a handful of bug fixes. Unlike the usual releases, these fall between and don’t need to be advertised with FB and Youtube posts.
Automated testing to catch regressions
A dedicated QA
A regression testing checklist before you ship a beta/rc/stable
Splitting things into smaller parts and getting code reviews
I’m hoping we can band together on this one and the community has some ideas too.
I was building a simple static site earlier this week and ran into most of the bugs you mentioned. Spent half the time building, and half the time figuring out why things weren’t working.
Updated to 1.5.1 hoping it would fix this issues, and while it did for many of them, it introduced a bunch of new ones.
I reverted back to the stable, but now feel like I’m in a position where neither of them are stable. Not a great place to be in!
I would also very much agree with your point about Cwicly’s release cycle. It’s a builder I’ve been experimenting with lately, and the small releases often mean my bug reports get fixed the next day.
I love the direction that Bricks is heading, but from my personal experience a focus on stable releases would really be helpful.
We are not aware how the team tests the builder right now but it’s lacking for sure. I think automated regression testing is the way to go. It allows the team to release updates at their comfortable pace as well as reduce the number of bugs.
Zion do a very thorough testing before every release but then it is very slow with releases. I like Cwicly fast release cycle with bug fixing but the user base there is much smaller. It is yet to encouter all scenarios which so many Bricks user put forward for Thomas & team to test. I am enjoying Pinegrow more now a days. There is no update to be done to the code once you push it. But it will not work for every body.
Just wanted to say I’m a huge fan of this style of release cycles for various applications I use. With Bricks we’ve seen some major bugs in various which take weeks to fix as it waits for the next major point release (1.4, 1.5, etc) when it would ideally be fixed in days in a point-dot release instead (1.5.0.1 for example). Of course Bricks is moving very fast already, I don’t mean to say it isn’t as the rapid pace of new features is absolutely incredible and something for the Bricks team to be very proud of. I agree too though the stability would be nice to have too and hopefully can be addressed in more rapid smaller releases. Would much rather see even smaller (but rapid) iterative releases which may just be smaller instead of saving things up, especially when it comes to the user-reported bugs encountered.
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.
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…
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’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
