Jump to content
thirty bees forum

Recommended Posts

Posted (edited)
On 12/6/2021 at 9:15 AM, the.rampage.rado said:

It will be released but until then you can update to edge. It's tested almost daily.

Thank you for the answer but this is not the solution. Bleeding edge is intended just for "testing sites". It means, as I understand, it can be buggy and is not considered as stable bugfixing build.

Thirtybees really needs stable bugfixing (regular) releases.

Edited by luksl
Posted
1 hour ago, luksl said:

Thank you for the answer but this is not the solution. Bleeding edge is intended just for "testing sites". It means, as I understand, it can be buggy and is not considered as stable bugfixing build.

Thirtybees really needs stable bugfixing (regular) releases.

With the current dev onboard you can be sure that every commit is tested and he knows the ropes very well. I think in the past 6 months I saw one reverted commit.

 

Feel safe to update to edge when you notice something cool that you want to be fixed in your installation. Bugfix versions will come too.

Posted

I always run the latest bleeding edge on my live site, since bleeding edge option was introduced in core updater.

So far without any problems.

 

  • Like 1
Posted
3 hours ago, luksl said:

Thank you for the answer but this is not the solution. Bleeding edge is intended just for "testing sites". It means, as I understand, it can be buggy and is not considered as stable bugfixing build.

Thirtybees really needs stable bugfixing (regular) releases.

I agree that regular hotfix releases should exists. 

When I say hotfix, I don't really mean bugfix release. I mean release that fixes those issues that were introduced in the last release only. And only those issues, for which fix is very well understood and the confidence level is very high. 

There is not many such issues.

Since 1.3.0, there were exactly 3 commits like that: https://github.com/thirtybees/thirtybees/compare/1.3.0...1.3.x , four lines in total.

Why not include other bugfixes into such release as well? Well, because it comes with potential of creating more problems, mostly because of the non-linearity of the codebase. Even if the fix/commit seems safe, it might not be safe for cherry-picking to different branch. For example, imagine this one line fix in main branch

$price = (float)Tools::getValue('price');

to

$price = Tools::getNumberValue('price');

On the first glance, it looks quite safe to cherry pick and transfer this commit from main to bugfix branch. After all, it's but single line. But it is never so simple. In this case, the getNumberValue method was introduced only recently into main branch. If we transfer this code without the commit that introduced the 'getNumberValue' method, it would break. 

Problem with official releases is that it takes a lot of time. Like 8 hours of mundane manual work. Of course, we could automate this. But to automate this we would need a lot of time as well. But until this is automated, there will be just a few releases. 

As a workaround for the time being, I plan to introduce third channel into 'core updater'. Currently we have 'Stable' and 'Bleeding Edge', but soon we will have 'Stable', 'Stable with hotfixes', and 'Bleeding edge'. Please suggest better name for the new channel 🙂

  • Like 4

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...