Openmage 1.9.x v 2.x #3050
-
Hey guys, firstly HUGE thankyou to everyone who contributes and keeps this project running. I just wanted to start a general discussion in particular about where the 1.9.4.x branch is heading. When M1 had end of life, I was under the impression that the 1.9.4.x branch would be mainly for bug-fixes, security patches and always backwards compatible. New features and additions would be added into the 2.x branch. I thought this was the plan at least. Is this still the case? If so, I am concerned by a number of issues which have appeared lately, namely here: Now fair enough, that's a one off. But reading the pre-release notes for 1.9.5.0-rc: https://github.com/OpenMage/magento-lts/releases/tag/v19.5.0-rc1 I see that there are various progressive things like removing libraries, removing themes, and it's even stated "a lot of the changes could have impact on current installations." I do not want to create an argument, but this seems to moving away from the original idea of the 1.9.4.x branch. For new features, updating code etc, I thought that is what the 2.x is for? Can we simply keep 1.9.4.x as a bug fix, security patch and always backwards compatible branch? @fballiano I appreciate_everything_you_are_doing with this project, I love it. But I also know there are tons of merchants (such as myself) who don't want new features or potential bug causing changes. We just want to run our stores, contribute to the community is some small ways and have security patches. I feel the 1.9.4.x branch should be for this purpose. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
@Dirtyhair1 I totally agree with your view and I've always had, I had various discussions with some other maintainers and at that time I was in the smaller minority so I had to accept to modify v19 if it was considered backward compatible. again, always been agains, but this is not my project (I'm just very vocal) and I've to comply with what the majority decides. This is why I started this RFC OpenMage/rfcs#6 to make v20 the default and v19 a patch only. I've also posted numerous time on this repository (in the discussions and in issues/PR) that I was against the way we were managing the branches. But I prefer to keep moving and break something compare to die because we don't do anything, so I still stand behind what we did as a group. I think this situation will be solved in the near future with OpenMage/rfcs#7 |
Beta Was this translation helpful? Give feedback.
-
I think that the delimitations between versions should have been made better, without numbers like v19 or v20, which created confusion in my opinion: Magento 1 LTS - continuation of 1.9.4.5 only for compatibility with PHP, MySQL and bug fixes, so that it remains as close as possible to the original Magento. Thus the desired BC is ensured. OpenMage - remastered Magento 1 platform. What exists now is not far from these two options, because there have always been contradictory discussions related to the changes and they were adopted based on majority decisions. If there had been problems, maybe we would have reported, but for the time being I do not have consistent feedback from several OpenMage users/developers, I think that what has been done so far has been in the right direction. That "serious" problem with WSDL could be prevented if an important tool in OpenMage called Web_Notification is properly used. Unfortunately, communication between OpenMage and its users is still non-existent. This tool had to be put into use since the spring of 2020 when it was known that the Magento team would close the shutters on version 1. The fact that some libraries like Zend Framework were excluded from repository made this step necessary. Indeed, when git clone command is used, everything doesn't come anymore like before, but Composer solves the problem. In addition, the periodically released download versions include everything necessary for proper running, including those libraries. Old themes, Internet Explorer, I don't think we should worry anymore, it's just old stuff carried too much to the present day. In the near future I would worry about compatibility with PHP, for non-updated extensions where there is no longer support from the developers. OpenMage at this moment is a solution to be administered in-house as it should be and not at all through a 3rd party. As long as I use Debian which has LTS until 2026 on PHP 7.4, I won't have any problems. When the Debian 12 version comes out, it will probably be shipped with PHP 8.1, and OpenMage runs on this version. So I could say that this platform can be used until 2030 - 2032. I also have stores that run X-Cart 4, a store from ancient times that I contributed to. The platform is not object-based but procedural. A few clients have become attached to it and it is important for the business to be functional and generate money. What we need now is a professional reorganization and more active people to process Issues and PRs. |
Beta Was this translation helpful? Give feedback.
-
Is OpenMage v20 based on Magento v2? |
Beta Was this translation helpful? Give feedback.
I think that the delimitations between versions should have been made better, without numbers like v19 or v20, which created confusion in my opinion:
Magento 1 LTS - continuation of 1.9.4.5 only for compatibility with PHP, MySQL and bug fixes, so that it remains as close as possible to the original Magento. Thus the desired BC is ensured.
OpenMage - remastered Magento 1 platform.
What exists now is not far from these two options, because there have always been contradictory discussions related to the changes and they were adopted based on majority decisions. If there had been problems, maybe we would have reported, but for the time being I do not have consistent feedback from several Open…