opencart-3
opencart-3 copied to clipboard
opencart
Why not do a 3.0.3.9 release
Why not do a 3.0.3.9 release.
https://www.opencart.com/index.php?route=cms/download/history
I got no objection to rewind back since that version has never been used anyways, but the reason why I simply set the version v3.1.1.0 was due to the true nature of PHP 8 compatibility, subscriptions system (still awaiting the final edition), new controller/startup implementation, GDPR which I thought that increasing of .1 version might been a bit unrealistic.
However, I can lower it back to OC v3.0.3.9 release if it's what you want.
If we draft a release, it will also mean that the next released version, aside from this one, will still contain the fallbacks whereas users will still be stuck in since ages. Which is why, rather, I was expecting to have the new subscriptions system built-in before the PHP 7.4's deadline in order for users to maintain their active recurring users via the new subscriptions system. Since, right now, we don't have migration tool built-in from the core to maintain those users.
actually if u want to start on the subscription system on 4.,x again i would be grateful. im getting side tracked a lot by other jobs when i just want to code the next version.
Since the issue is by design, we're both stuck on the same level since all I need from you is the roadmap whether to know if we keep the type field from the database in order to declare it from the admin subscriptions? People wants to eventually upgrade to OC 4 but the same risks and impacts are going to occur during the transition since store owners still won't be able to complete their final settlements with their transactions initiated by their clients and their service providers.
All I need to know is which direction will you take with the type field from the subscription table and from the admin since, according to your statement last time, you didn't want to add the type in the admin subscription while this field specifically is mandatory on the database which will obviously create a JSON popup error message from the admin.
Therefore, if you can provide the roadmap on this, while I understand you might be busy on other projects, that would definitely help me as pretty much everybody else so to proceed with their normal operations to their functions and processes since this issue has been happening for quite some time now.
If the type field can simply be declared from the admin and you can agree on this, I could definitely work on it shortly.
As for OC 4, sure I can work on it directly for the subscription system if you can give me access to the repository but first needs to be worked on the opencart-3 to ensure, by design, the integration goes as expected.
@danielkerr please don't release the opencart-3 branch as 3.0.3.9. There are too many changes that will be incompatible with themes and extensions. Nearly all the function and method definitions have changed. Changes to the default theme files. All arrays have been changed to [] along with other code style changes. Most themes and alot on OCMOD extensions will have issues.
No way can it be classed as a PATCH version. https://github.com/opencart/opencart#versioning
Functions and method definitions have not been changed. They've been aligned maybe but the functions and method conventional names remained the same since modifications were made.
They have been changed. To give just one example.
Before. https://github.com/opencart/opencart-3/blob/ff899f5bd3f7a4444bba95be56977cf8ee03900f/upload/catalog/model/catalog/product.php#L7
After. https://github.com/opencart/opencart-3/blob/da0e0ae8867d07547d87ace6ea19cfc41bf518b9/upload/catalog/model/catalog/product.php#L7
Any OCMOD trying to match that line would fail.
Yes, as it looks pretty close to this one:https://github.com/opencart/opencart/blob/master/upload/admin/model/sale/order.php#L72 . That is called evolution, It's ironic, isn't it? A season ago, there were days where we could just pull up a chair and sleep on it 24 / 7 on the maintenance branch until I came along. Since the past season, a brick load of work has continued to be done on this repository even though OC 4 was already released. Yet, no OCMod out-of-the-box with OC 4 can be used (no objection). However, since this week on the OC forum, people are suddenly eagered and looking forward into upgrading to OC 4. Yet, no OCMod out-of-the-box with OC 4 can be used but suddenly doesn't seem to disturb anybody on that thought.
What users are, then, providing with their feedbacks on the OC forum is that extensions are not a priority but rather to focus on a new core in order to maintain their extensions in the future. For that, I got no objection at all. The PHP deadline is getting near, as it still stands. There are other issues encountered with OC v3,x releases as they were also reported by users from this repository that dedicated their time to provide the source of information as pull requests and that cannot be disregarded. Today, however., after a season has passed, you are still the one who acquires to postpone this release so that users can be stuck into the same situation they were last time, the time before, and so forth, just so that people can keep their extensions to where they are without elevating.
These postpones have been going on for many years, now. Therefore, it is time for a change.
You have misunderstood what I have been saying. I was suggesting when it is released it has an appropriate version number. You had it right in the first place with 3.1.1.0. Although I would go with 3.2.0.0 to avoid confusion with the 3.1 alpha version.
It is harden to see where I may have misunderstood in this case since you seem to be requesting this version to be set higher than 3.0.3.9 release for extension reasons as you stated on the above. However, regardless of the higher version release it will be, extensions will often, if not always, require modifications. Surely, a delay can be imposed as to know what the next version release will be as it used to be v3.1.1.0 previously but was suggested to be lowered to v3.0.3.9 on the topic.
That fact that your post was about how your version is closer to version 4 made it clear you didn't understand.
The version may have been suggested in the original post (probably because they didn't know what changes had been made), but once you explained the changes you had made, the reply was.
i mean draft a release. so i can link to it. call it what ever u want
Any release could have an impact on compatibility. It's good practice that the version number should reflect how much has changed. Given your posts about how much you have changed and looking at the commit history, it's clear that a higher version number is required. As you had originally concluded.
We'll see. Right now, it's been suggested to lower the version and it's been done.
It was suggested the version be lowered, the version was just assumed. You misunderstood and lowered the version.
I have to agree with ADDCreative:
The majority of existing OC 3 extensions will work on 3.0.x.x_Maintenance, the latter is just a bugfix release of 3.0.3.8, with added PHP 8 support.
opencart-3 went beyond that, requiring many OC 3 extensions to be rewritten or adapted in order to work with opencart-3.
Therefore, please use at least 3.0.4.x, or better, 3.1.x.x, as your version number.
You could agree as much as you want on each other, but the reality is the guy on the top takes the last decision on that, regardless. As my first reply on the topic state, I got no objection on which next version it's going to be since it's not our product nor our repository in order to make that decision.
Therefore, while I stand corrected in regard to the extension modifications, version 4 will also take a lot of time to make changes which means that Event triggers will still shorten the time as opposed to play with core codes or to use XML. By the eagerness for everyone to move on the next level, OCMod still won't be available by default unless extension developers have something to hide with their own extension engine. However, it would still be an extension which means it's not originally supported by Opencart.
The rest goes to time management, nevertheless, which will include 99% of the bug-fixes and I am counting a left-over of 1% in case nobody's perfect on that. At least, the workload will be reduced after waiting so long to use a flexible release.
Furthermore, I don't believe it was ever encountered to have a x.x.4.x release before and I doubt that's going to happen now.
OK, let's ask Daniel!
@danielkerr Please Daniel, let's go with a 3.1.0.0 release for opencart-3, because the changes done in opencart-3 are quite substantial compared to 3.0.3.8.
The PHP deadline is in a month and a week. There's no time left for that. People needs to get ahead with the changes, not falling back for another 5 to 10 years as OC 4 already demonstrates as the next changes.
@danielkerr: Now would be a good time for testers to evaluate the changes. It looks like the task has finally been completed the way it should.
@danielkerr: Subscriptions system has now been fully integrated. I may need to review the #button-filter forms in the admin. Apparently, when hitting the filter button, queries don't always show on the URL. I was able to reproduce the issue with the old recurring and the new subscription forms as they both have been fixed already. Other than that, we should be good to go with this release.
@Daniel: Can we please use version 3.1.0.0 or higher for the upcoming opencart-3 branch, as it has so many changes making it not backwards-compatible with OC 3.0.3.8, nor the 3.0.x.x_Maintenance.
The 3.0.x.x_Maintenance is at the moment the only OpenCart release supporting all PHP 8.x versions, including 8.2. It's much more closely based on OC 3.0.3.8 (unlike opencart-3), and also has some bugfixes which are yet to be ported over to opencart-3.
@daniel: Can we please use version 3.1.0.0 or higher for the upcoming opencart-3 branch, as it has so many changes making it not backwards-compatible with OC 3.0.3.8, nor the 3.0.x.x_Maintenance.
The 3.0.x.x_Maintenance is at the moment the only OpenCart release supporting all PHP 8.x versions, including 8.2. It's much more closely based on OC 3.0.3.8 (unlike opencart-3), and also has some bugfixes which are yet to be ported over to opencart-3.
You know you got some nerves to come in here and state how your repository should take place instead of this one. While we both may post this kind of crap on the OC forum, at least, I don't post it in the maintenance branch since I would rather maintain the community rather than trying to get rid of it while you're the one who came in here to post about this.
I have been working on this repository for the past 6 months to get this tree up ahead as I have delivered what needed to be done so far. If there are relevant bug-fixes that needs to be added, lately, I haven't seen any posts about them and even less on your behalf. In fact, I have seen none on your behalf in order to improve the platform on this repository while I did post in the maintenance branch in the past and way long before you came along.
Therefore, nobody needs to take this since Github regulations do work by repositories and you just broke into one where it is separated from the area you have been assigned from. If people still believe there are still other solutions that needs to be brought in with their pull requests, they are more than welcome to do so. On the other way around, if they decide to remain silent rather than helping, they are also welcomed to do so but that is nobody's problem except than bringing this on themselves.
Time has been consumed on this project in order to move forward. The community sure don't mind affecting their extensions when it comes to upgrade to OC 4, then nor should it create distractions to upgrade to OC v3.0.3.9. OC v3.1.0.0, as you suggested, is already enlisted in the OC downloads page at: https://www.opencart.com as an alpha / beta release. There should be no need to duplicate this version.
I have already increased the OC version number before. However, this exact commit we're posting in has been suggested otherwise by the founder. It's his tree, then he decides of the version that will be used. At least, I don't bother anyone nor anyone else about it the way you're doing.
With all that being said, rather show the right example for the community by moving rather than offering fallback solutions to the people. We've been through those times and things evolved since. Therefore, we still need to move forward!
@TheCartpenter: I appreciate your concerns, was just trying to be helpful, and avoid confusion for end users.
I am simply too busy at the moment, with upgrading and documenting extensions for the upcoming OpenCart 4.0.2.0, and the 3.0.x.x_Maintenance was just a quick shot for supporting the PHP 8.x releases, it has no new features compared to 3.0.3.8.
@TheCartpenter: I appreciate your concerns, was just trying to be helpful, and avoid confusion for end users.
I am simply too busy at the moment, with upgrading and documenting extensions for the upcoming OpenCart 4.0.2.0, and the 3.0.x.x_Maintenance was just a quick shot for supporting the PHP 8.x releases, it has no new features compared to 3.0.3.8.
Well, guess what buddy? You're not being helpful right now; facts being that you posted in this repository on this tree that has nothing to do with it. There are no confusions with the users, since no recent change requests have been posted on this repository especially since the latest codes were finalized on my behalf.
Therefore, being busy on a project of your own doing does not justify the means to alter somebody else's course while we were both assigned on different projects as you are absolutely right here - there are no new features compared to v3.0.3.8 from the maintenance branch as being the reason why I had to work on them.
To avoid 'future' confusions with the end-users, as you say, then I will ask you to remain on what you've been assigned in the maintenance branch as I will stick into mine on this tree.
@TheCartpenter Is this branch ready for production ?
Aside from the PHP 8.2 integration that needs to be completed, it's quite safe to put it in production.
Hi there This brunch hasn't changed for 3 weeks, are you ready for the new version? Is version 3.0.3.9 going to be released?
@TheCartpenter Is this branch ready for production ? Aside from the PHP 8.2 integration that needs to be completed, it's quite safe to put it in production.
Thanks for your hard work and maintain it,
I did install this repo and run the test on https://pagespeed.web.dev/
It is reporting 9 vulnerabilities detected
Do you have any plan on fixing these or is there patch for it.
@TheCartpenter Is this branch ready for production ? Aside from the PHP 8.2 integration that needs to be completed, it's quite safe to put it in production.
Thanks for your hard work and maintain it,
I did install this repo and run the test on https://pagespeed.web.dev/ It is reporting 9 vulnerabilities detected
See on the MB if those vulnerability count would state 0 as well. I would doubt it.