View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003234 | OXID eShop (all versions) | 1. ----- eShop frontend ----- | public | 2011-09-08 13:25 | 2012-12-10 14:38 |
| Reporter | dklingmann | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | not fixable | ||
| Summary | 0003234: Make proper version numbering | ||||
| Description | As this was really bugging me out that we had to upgrade from 4.5.0 to 4.5.2 here is my comment about how version numbering works. There is a major, a minor and a bugfix number in the version number. When there is a bugfix release, I expect it to take about 5 minutes to just copy files and I'm done. Also, deprecations have nothing to do here. Things are supposed to be working BETTER than before after doing an update to a bugfix release. When I update to a new minor version I know it might take me a day to migrate some small changes. It might even break some small things which are relatively easy to fix. When I update to a complete new major version it might take me a week straight but I will know it before I even attempt to do it. Things have changed and a lot of stuff will possibly break. Right now, we're working like 3 days on migrating from 4.5.0 to 4.5.2, a whole new CSS file came to life in that time called oxid.css which is now overwriting a lot of my own custom CSS styles because instead of doing only .className its now div.className which means I have to go through every line of css to check what element is referenced so my styles are working again. The current update was nothing more than a huge clusterfuck for us. I'm not pleased and that's my feedback. | ||||
| Tags | No tags attached. | ||||
| Theme | Both | ||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
|
|
Reminder sent to: dklingmann Hi, You are fully right regarding concept for version numbering and updates between versions. Just, as I mentioned in other channels (dev-general, forums) that version 4.5.0 was in really bad quality and the next Patch (4.5.1) was an rather the exception than the usual bugfix version. As major feature in 4.5.0 version was new design layout, lot of bugfixes for that needed changes in the frontend templates. Also, by doing some stuff we found that after removing deprecated functionality (in 4.5.0) some parts were not working at all or not working properly and needs to be rebuild from scratch. What we also did in 4.5.1 version. So basicaly 4.5.1 was big exception from usual version release procedure, but we wanted to make this version more usable and stable, so needed to do that kind of stuff. The update between 4.5.1 to 4.5.2 already fits to the defined concept (no DB changes, no changes in frontend templates, and so on). Also we are thinking further how to make work for module writers more easy and implement some features for more convenient maintenance of their changes. So, sorry that it's caused lot of work for you and others. We'll try to do our best to avoid such cases in future. Best regards, |
|
|
Sorry, for the resolution, but that's fits best (having in mind others, like won't fix, cannot reproduce and no change required) :) We do respect the version numbering and effort of people, who also are working on this and will try to keep the line in future. The entry here closed. |
