OpenCart 1.5.1.3 Released

You can do patch only, but get the system/library/cache.php file from the full zip
patch only has only changes from 1.5.1.1

Thanks for your prompt response! Do you think its the right way to go in order to maintaine extensions links?

gfrgrocery wrote:When I upgraded, I lost my Import/Export Tool and my Blog tool from the Extras menu... not sure if I just missed something or if that is a bug to report. I tried re-installing those add-ons using their versions which are compatible with 1.5.1.3 and still no-go. I had to revert to a pre-upgrade backup in order to get them back.

if you were using the vqmod versions you have to reinstall vqmod by going to vqmod/install/ after you do an upgrade because every upgrade overwrites the index.php files since that's where the version number is stored.

Xsecrets wrote:

Qphoria wrote: Perhaps we should revisit and maybe rethink the versioning to be clearer and something that we can all agree on. It is very tedious to develop addons for opencart when the API keeps breaking.

well seems like everyone has thought about it and agrees but Daniel.

I was hoping that Daniel would response to our (ongoing) comment on how he handles his versions.

stop bothering me with this crap.

Patch Only Version:
I've compiled a zip of only the changed files, for those that want to limit the upgrade to only the changed or new files.
Only use this zip if you have an existing 1.5.1.x version

Is there a chance that I can assume that because were running version 1.5.1 can I forget about the .x on the end and just use the changed files from Q or have I got to do the full zip method?

Many thanks

Daniel wrote:stop bothering me with this crap.

Yep, that sounds like a Daniel response.

Yup. It's really sad that such a great piece of software could really benefit from being forked just because one guy doesn't give a crap.

trev.pope wrote:

Patch Only Version:
I've compiled a zip of only the changed files, for those that want to limit the upgrade to only the changed or new files.
Only use this zip if you have an existing 1.5.1.x version

Is there a chance that I can assume that because were running version 1.5.1 can I forget about the .x on the end and just use the changed files from Q or have I got to do the full zip method?

Many thanks

1.5.1.1 had 2 files changes from 1.5.1 that won't necessarily be in the patch because it was diffed against 1.5.1.2

Qphoria wrote:

trev.pope wrote:

Patch Only Version:
I've compiled a zip of only the changed files, for those that want to limit the upgrade to only the changed or new files.
Only use this zip if you have an existing 1.5.1.x version

Is there a chance that I can assume that because were running version 1.5.1 can I forget about the .x on the end and just use the changed files from Q or have I got to do the full zip method?

Many thanks

1.5.1.1 had 2 files changes from 1.5.1 that won't necessarily be in the patch because it was diffed against 1.5.1.2

Cheers Q, much appreciated!!

Hello Guys,

About version-numbering Opencart, maybe you are right, versioning could have some improvement, like all the things in our live. Keep in mind, Daniel, Qphoria and others are making an excellent job with this software, and how many of you, are paying something to them? We should not give them so much pressure. Lots of the comments I am reading are nearly inappropriate. Lets discuss Opencart in an appropriate manner and we all could do a good software even better.
The way we writte comments, matter.

Thanks to the Opencart developer team, for their work.

Daniel Bassa

" Added utf-8 helper functions so there is no need for mb extension to be installed. "

Where is this changed ? Im just looking to change this part of the upgrade.

Daniel wrote:stop bothering me with this crap.

We know and that is one approach

I would prefer a business kind approach, more in the line of:

"OK, I see now. And even-tough I think it is just crap I believe that OpenCart, and more important it's users, could benefit from a well thought through version and release management", "Especially Extensions builders who spent time and money developing Extensions that create an even wider user-base because they add more functionality to OpenCart.", "In the end all I want is to make OpenCart the number one Cart , like osCommerce used to be."

dbassa wrote:About version-numbering Opencart, maybe you are right, versioning could have some improvement, like all the things in our live. Keep in mind, Daniel, Qphoria and others are making an excellent job with this software, and how many of you, are paying something to them?

Daniel has made literally hundreds of dollars off the extensions I sell through the OpenCart extension store. Because of that, it is a business relationship, which is why I feel I can ask that he conform to standard versioning that benefits the ease of extension creation. The quicker developers can upgrade and create extensions, the more it benefits everyone (including Daniel, myself, and the OpenCart community).

Of course, Daniel is always free to disagree (which he does), but I still think I have the right to suggest ways he could make everyone's lives easier.

Johnathan wrote:

dbassa wrote:About version-numbering Opencart, maybe you are right, versioning could have some improvement, like all the things in our live. Keep in mind, Daniel, Qphoria and others are making an excellent job with this software, and how many of you, are paying something to them?

Daniel has made literally hundreds of dollars off the extensions I sell through the OpenCart extension store. Because of that, it is a business relationship, which is why I feel I can ask that he conform to standard versioning that benefits the ease of extension creation. The quicker developers can upgrade and create extensions, the more it benefits everyone (including Daniel, myself, and the OpenCart community).

Of course, Daniel is always free to disagree (which he does), but I still think I have the right to suggest ways he could make everyone's lives easier.

Yes, I am sure things can be better. But We must take care about the manners and make this project get better. I don't know Daniel at all, but I am sure he is doing the best for Opencart.

Daniel Bassa

the next one is going to be 1.5.2 it will have the order editing system and pdf invoices.

is 1.5.2 ok?

Daniel wrote:the next one is going to be 1.5.2 it will have the order editing system and pdf invoices.

is 1.5.2 ok?

Sounds good to me. I don't think those features warrant a change to 1.6, but we'll see what everyone else has to say.

Daniel wrote:the next one is going to be 1.5.2 it will have the order editing system and pdf invoices.

is 1.5.2 ok?

1.5.2 is fine for the next version, but this version should have just had bug fixes in it and the tax stuff and moving json should have waited to go into 1.5.2

I think 1.5.2 will be fine.

I general, if we could use the following simple version numbering standard:

1.x.y.z

where

x indicates major new changes, including differences in the API or DB
y indicates new features, but keeps the API or DB the same or at least backward compatible
z indicates a bugfix release (can be omitted the first time a new y or x is introduced)


So we'd expect for example something like this in the foreseeable future

1.5.2 (new features e.g. order editing and PDF invoices)
1.5.2.1 (future bugfix release for 1.5.2)
1.5.2.2 (2nd bugfix release for 1.5.2)
......

I think that's how most OpenCart users and contributors interpreted the version numbering.

JNeuhoff wrote: 1.5.2 (new features e.g. order editing and PDF invoices)
1.5.2.1 (future bugfix release for 1.5.2)
1.5.2.2 (2nd bugfix release for 1.5.2)
......

I think that's how most OpenCart users and contributors interpreted the version numbering.

I think that is how we've settled... but on some forums and blogs, I can use a module made for 1.2.0 on 1.2.9. Are they not changing that much or are they just doing it smarter?

It is a tough balance working out new features yet not breaking the API for 3rd party addons. It is painstaking that I can't make a mod for 1.5.x but I have to update the code almost monthly to support the idea of the month that could have likely waited until the next major version change.

In this case, based on your scale, the taxRate change in 1.5.1.3 broke the API for shipping and order totals which should have been 1.6. The 1.5.1 change for modules arguably could have also been a major change tho, uninstall/reinstall of the modules was the quick resolve.

It is understandable that you don't want to wait forever to add new features, and trying to add conversion functions can be cluttering if they are in the same file.

Perhaps we need a helper class called "deprecated.php". And this will be the place for conversion functions for the remainder of the "major" version.

For example, the taxRate() change could be moved there and the taxRate() function would then change to a bridge between the new function and the expected return value of the old function. This would give leeway to update your extensions. There are some underlying bits tho, as $this->tax->getRate() wouldn't work if the function was moved to a helper... so maybe some code to include the deprecated class in each library class as the alternate location.

dunno.. just shootin out ideas.

Qphoria wrote: dunno.. just shootin out ideas.

Perhaps implement the old Tax::getRate($tax_class_id) in a VQmod XML file and let it call in turn the new methods? This way there might be no need to change all the addons, have to look into it. Certainly my Google Checkout module is broken now in 1.5.1.3 because of the changes with the tax.