Thirtybees roadmap

[ricardolobo]

Hello there!

I would like to know if there's somekind of roadmap or release schedule for Thirtybees?

It would be great to know what's the plan for this project.

Thank you.

[Tomik]

https://thirtybees.com/contribute/roadmap/ kinda like that except no release schedule and maybe thats better we all know how fucked up PS was

[lesley]

We still haven't found an adequate way to display a roadmap of our plans. But like was mentioned, sticking to a timeline is hard, because then sometimes thing get rushed.

[datakick]

Can we get some update on future plans? There are bits of information scattered all over the forum, but it's very incoherent. I know there will be work on new updater (although I see this feature as an unnecessary overkill), and I guess there's work in progress on gdpr module. Anything else? What features, if any, are planned for upcoming release 1.0.5?

Also, what features are planned for next major 1.1.x version, and what is the timeframe? For example, @lesley said that there are plans for integrating some page builder into the core. I also have plan to build a paid module with similar functionality, and at the moment I'm not sure whether it makes sense or not...

[jmeca]

Hi, there: Well it would be very interesting for me too, I already have a very advanced site with this system https://ventaregalo.com and after having worked so hard it would be a shame if I lost it.

[Traumflug]

What features, if any, are planned for upcoming release 1.0.5?

v1.0.5? That's later this month. There will be a module validator. Maybe some people noticed it, the v1.0.4 release wasn't as seamless as making a release should be. All the module and theme upgrades got forgotten, even the already distributed ZIP file had to be corrected. So I started an effort to make not forgetting such things much easier.

Probably this sounds boring to many, it doesn't change much to the merchant/customer experience. Still I consider this to be important, because a successful project needs a strong foundation.

The new updater module will add to this as well. No more wrestling with patches, just click and go ahead.

I already have a very advanced site with this system https://ventaregalo.com and after having worked so hard it would be a shame if I lost it.

thirty bees is open source, so you can't loose what you already have :-)

[toplakd]

@traumflug said in Thirtybees roadmap:

thirty bees is open source, so you can't loose what you already have :-)

One can always go with paid solution E-commerce. And will also have same problems with bugs, which also take time to be solved. Sometimes even longer than on open source solutions.

[Traumflug]

One can always go with paid solution E-commerce.

Then you can loose what you have. If the software maker decides to stop supporting the software your shop closes. Can't happen with open source.

[toplakd]

Exactly. So bitching over free open stuff is not nice (many do it), as they can always go towards paid solutions and bitch there :)

[datakick]

@traumflug said in Thirtybees roadmap:

v1.0.5? That’s later this month. There will be a module validator. Maybe some people noticed it, the v1.0.4 release wasn’t as seamless as making a release should be. All the module and theme upgrades got forgotten, even the already distributed ZIP file had to be corrected. So I started an effort to make not forgetting such things much easier. Probably this sounds boring to many, it doesn’t change much to the merchant/customer experience. Still I consider this to be important, because a successful project needs a strong foundation.

Thanks for info. Module validator is definitely useful and needed functionality. But it's not a feature, it's a build tool. And that surely doesn't require a release.

Anyway, I'd really like to know if there is some sort of short/mid/long-term plan, to see the direction this project is going to. Should we expect mainly bug fixes, or are there some features on the table as well? If so, how are the features prioritized / who decides what will be worked on? How many resources do you have at your (company as a whole) disposal - are we talking about 10 hours a month, or is it 200 hours/month?

I understand that you are doing this for free, and that we (community) are not entitled to anything. But still, if you want this project to succeed, you need to commit to your vision and be accountable for it. Otherwise you won't be considered as a serious partner by most merchants (or other developers)

[nickon]

@datakick I would really like to hear your opinion on why the updated is overkill. Because if it is maybe @lesley and @mdekker could use the time/money to build something that is more usefull.

[datakick]

@nickon said in Thirtybees roadmap:

@datakick I would really like to hear your opinion on why the updated is overkill. Because if it is maybe @lesley and @mdekker could use the time/money to build something that is more usefull.

Sure, why not.

I believe that serious merchants don't need new release every two weeks. That's way too often. We have to remember that this is legacy codebase - Prestashop/Thirtybees source code is big bowl of tangled spaghetti, and every change can cause some bug. So every release is a potential thread, and should be accompanied with thorough re-test of your shop (or at least basic functionality).

I'm sure that most merchants that has been running ps/tb for a few years has already experienced some issues with version upgrades. It can be pain, especially when you have many third-party modules. It's tolerable when you are upgrading your shop every 6 month - you just close your shop, and dedicate one weekend for upgrade and thorough retest. But I'm pretty sure most merchants wont be undergoing this task every two weeks, or every month.

I think that stability is what merchants value the most. I can see them using this new updater on their dev/test sites to test new codebase. But how many merchants have test sites?

From my perspective it's more than enough to release new version once every 6 month. I understand that manually create release can be time consuming -- but how much time can it take, really? Maybe a day or two. How much time will this new updater take?

Just my 2 cents... very possibly I'm completely wrong in my assumptions :)

[toplakd]

One, who have read complete post about updater crowdfounding, understands why they decided for it. 26 have read it for sure :) and donated.

[lesley]

@datakick The updater is the first step to fixing this. The updater is going to be based off of Git practices for code management and for merging changes. Just because the core code base is legacy, it does not mean that the most important and time consuming parts of the new updater module need to be legacy as well. The module wrapper does need to be though.

What the updater is giving way to, is for us to start fixing the tangled legacy code base. It will allow us time to work on the code base. Like @Traumflug mentioned earlier, he is working on scripts to make the build process more stable and automatic. The updater module is doing the same thing. As much as we would like for it to be the case, just downloading the repo, running composer, and zipping it back up is not the way the package builds. There are translations, database changes, submodules that get out of sync. Before we started working on the scripts it took around 4-5 hours to build a release. Now it takes 4-5 minutes. With the updater we have the issues. The same amount of time, but with a spaghetti codebase that is falling apart. So not only are we making updates, we are patching the updater to actually work too. This is why we want to make an updater.

Saving time is the only way we are going to get ahead with a small team. We have to look at our processes and refine them to cut the fat out. Two months ago if we decided to release a new version with an update we would be looking at 10-15 hours of work. Now we are looking at around 8. Once we get the updater finished we will be looking at 10 minutes worth of work. That is 9:50 that can be spent somewhere else.

As for time and plans. In the last month the GDPR module has had over 200 hours worth of work. Its a big fix to a tough problem. A problem we do not feel is handled correctly by most of the other modules on the market, so we are trying to handle it correctly.

As far as a rough roadmap, this is what we have discussed so far, but nothing is set in stone yet.

1.0.x - just bug fixes

1.1.x - modernize the front end, convert to bootstrap 4 and have a new theme

1.2.x - modernize the backend, convert to bootstrap 4 and have a new theme

Of course features will be added permitting they will not break things, but those are the main points.

[hubbobubbo]

@lesley I like the way you think about 1.1.x vs 1.2.x. I saw that Prestashop has just finished updating to Bootstrap 4 in the backend and I think they will support it in the Frontend for 1.7.5.0. I think it is more important to fix the customer facing issues first.

I am hugely interested in a modern bootstrap 4 based theme that covers the basic usecases with modern technologies.

Any rough timeframe on when you will be able to work on 1.1.x? Frontend uncertainty is currently the only thing that holds me back.

[datakick]

@lesley said in Thirtybees roadmap:

Saving time is the only way we are going to get ahead with a small team. We have to look at our processes and refine them to cut the fat out. Two months ago if we decided to release a new version with an update we would be looking at 10-15 hours of work. Now we are looking at around 8. Once we get the updater finished we will be looking at 10 minutes worth of work. That is 9:50 that can be spent somewhere else.

Of course I understand the benefits of updater, it's definitely a good thing to have. But I still think it's not needed at the moment. How much time will it take to build this? I assume at least 200 hours (and that's conservative estimate, considering all the features listed on the blog post). So you'll start saving time after 20 releases. If you will release every 2-3 weeks, you'll break even in a year.

Is such high release rate good? As I already wrote before, I don't believe merchants will update their store so often, it's too risky. You don't have a QA team that would run tests and sign off the release. Also, with this high release rate, the submitted code won't have a chance to mature in the branch - your developers won't have so much time to discover new bugs before the release. It's much more likely that bugs will make it to end users.

I personally think that 2-4 releases per year is more than enough. And with such release schedule it wouldn't make sense to invest so much effort and resources into an updater. That's why I think that the updater is an overkill. But this is just my opinion.

As far as a rough roadmap, this is what we have discussed so far, but nothing is set in stone yet. 1.0.x - just bug fixes 1.1.x - modernize the front end, convert to bootstrap 4 and have a new theme 1.2.x - modernize the backend, convert to bootstrap 4 and have a new theme

Thanks. Maybe it would be good if you guys selected some feature candidates, and let community decide/vote what should be implemented. Possibly let only patreons vote - that would be nice incentive for becoming one.

[toplakd]

I'm stil there for the updater as that was the main point of crowdfounding campaign. Se personaly I think it would be nice to bring the project to its end as based on reading it's in its final stages. And also not letting the crowdfounders on dry land :)

@datakick I think one can not vote for using the resources that were raised in campaign for specific project as that would kill the whole crowdfounding meaning.

But I'm sure you would get many votes if you said: I will make free PageBuilder module if I get enough votes. You could also start own crowdfounding campaign for your module: https://www.indiegogo.com/choose-your-platform And when money is raised you can start working on something else and let the founders know that their contributions were assigned to another projects as they were overvoted :) And than let us know how long you will be considered as a serious partner by most merchants (or other developers)

just my 3,5 cents.. :)

[lesley]

There really isn't a chance for us to not do the updater. We are going to do, it is being worked on now. Anything we suggest to do there will always be push back by some people. But none the less if we want to start rewriting the architecture, the updater is the best place to start. If we were to rewrite a major part of the software, now we would not have a way to deploy it shops.

In the end what the updater is, is the first step to automatic updates. Since we are doing it now, we can start testing them with shops on the 1.0.x branch at some point. The updates will be minimal and will likely not cause issues. Then when we have rewritten chunks of the software, the updater will be stable enough to work with them.

Going forward, I do like the idea of patreons voting on features for new versions though. It does make sense.

[toplakd]

I would extend the voting to a contribution voting. 10$ per vote. One could buy more votes if is needed. Each one 10$. So when one place a vote reservation could be made to his CC. After week of open voting (collecting $) the winning project would collect the money others would not be billed.

[datakick]

@toplakd I've never said that the updater project should be scratched - I'm sure tb is somehow bound by contract with indiegogo to deliver the promised goods. I was asked why I think this is overkill, so I answered. If you disagree with me you are welcome to raise your counter argument

[toplakd]

It was not my intention to offend you. But debate started to go into wrong directions. Yes. Some see benefits in updater, some dont. Every function has its followers. Im sure there will be another campaigns but would like to see that there was some kind of voting involved. But no voting on things which tb team thinks that are needed and will make their life easier. They are stil doing it for free and lasr campaign was just covering little drop in the ocean of spent free hours, which they could spend otherwise.

[nickon]

@datakick I realy like the way you think. This totally makes sense if you see it from a business man. But... People don't upgrade their stores because they know it will cause problems. Even minor things. PS has a reputation of not beeing stable. I always think twice before changing even micro things. On the other site I never dowded the automatic updater from wordpress. It never failed me. To me the biggest feature is I can go back to a previous version of a module or file if someting doesn't work as it should So by having a good updater you gain trust from the merchants. With trust you get more users. The more users the more money. The real challenge TB will face is when it starts to break compatability with PS. So things like this must be in place.

[dosbiner]

I vote for solid and bugs free multistore, warehouse, and ASM.

[Traumflug]

@datakick

From my perspective it’s more than enough to release new version once every 6 month.

Simply don't upgrade with every release, then.

Not upgrading means not receiving bug fixes, though. Making releases rarely means holding back these fixes from merchants for longer than necessary. Not sure what value that might have.

If you fear a broken shop after upgrading, that's a bit a different issue. And one much more worth tackling. The answer to this is, make releases more often. The smaller the release steps, the smaller the chance for regressions, the bigger the chance to get issues fixed timely.

Also, with this high release rate, the submitted code won’t have a chance to mature in the branch

The awful truth is, unlike wine, code doesn't mature by its self. Worse, even a big QA team wouldn't help much. This isn't MacOS, where every user has one out of a small set of hardware, running all the same theme, running all the exactly same applications. Diversity of shop installations brought in by hundreds of modules and themes is way to big to cover them all. With this enormous diversity, only real world installations can find eventual issues.

One answer to this is to make fixing newly upcoming issues ( = regressions) as seamless as possible. Which means many releases. Which is the reason why the upcoming updater module will support upgrading in even smaller steps, commit by commit. And which is the reason why this updater will support rolling back with a simple click. In a mockup I tried such a rollback (e.g. 1.0.3 -> 1.0.2) happened in less than a second, it doesn't even need a wait icon.

The other answer is automated testing of the basics. Every single commit gets exercised with a test installation and a virtual user clicking through the shop, up to doing a purchase. That's much better than what we had years ago.

[Beeta]

On 6/4/2018 at 5:15 PM, lesley said:

As far as a rough roadmap, this is what we have discussed so far, but nothing is set in stone yet.

1.0.x - just bug fixes

1.1.x - modernize the front end, convert to bootstrap 4 and have a new theme

1.2.x - modernize the backend, convert to bootstrap 4 and have a new theme

Of course features will be added permitting they will not break things, but those are the main points.

TB 1.1.x and 1.2.x will be a better PS 1.7 like TB 1.0.x is a better PS 1.6.x?

Are you going to use 1.7 base code for next TB major releases?

Edited February 3, 2019 by FooLab