Should Open Cart have more control over it's releases?

I appreciate what your saying Daniel, and I don't want you to think we are all being critical as if Open Cart wasn't an excellent piece of software then none of us would be here.

It's a suggestion though I do think you should listen to just based on some of the comments above, if you want to make Open Cart a real commercial piece of software. From a user point of view I want to come to your site and either download a paid or community version of your code and know that there are no silly mistakes in. Yes bugs do happen and come up and that is the nature of what we do and that's not the problem (and you could release patches as and when needed), but is it really that much more work for you to leave version 1.4.6 as the latest stable release and then version 1.5.0 as beta until you know that the bug list is down to 0 and has stayed that way for a few weeks. Then once it's sorted updated the latest stable release as 1.5.x and then carrying on working on what you have under development.

That way I know with complete confidence that when I download your code I don't need to keep checking daily as to whether there are issues in and that I don't have to keep going back into the software over and over again to correct things which if we all help you test wouldn't exist.

Your software is excellent and is a real contender to Magento, however you will never get any of the big software agencies or businesses using it till you have a more structured way of releasing the work you have done,

Jonathan
It would also mean as well you would end up with less queries hitting your inbox and forums for the issues that arise and we wouldn't need to have extensions that support 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5.... etc as none of these would exist as proper releases as 1.5.0 would be the tested version.

bouncybee wrote:It would also mean as well you would end up with less queries hitting your inbox and forums for the issues that arise and we wouldn't need to have extensions that support 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5.... etc as none of these would exist as proper releases as 1.5.0 would be the tested version.

Oh believe me, I know. There's no one who would be happier with less frequent releases than me, but I'm just trying to keep it realistic. People sometimes spend a lot of time writing posts and arguing why it's a great idea and needs to happen, but my point remains: it will only happen when Daniel wants it to happen.

(The good news is that Daniel mentioned this in his last update to the future of OpenCart, so we may finally be getting a more stable release schedule in the future.)

Johnathan wrote: (The good news is that Daniel mentioned this in his last update to the future of OpenCart, so we may finally be getting a more stable release schedule in the future.)

which post was this? I don't recall him talking about this in a while. I know before 1.5 was released he seemed like he had bended to the idea of structuring releases better, but I haven't seen anything like that since 1.5 came out.

He told me he is waiting at least 1 month between releases

I wish that he would start using SVN-version branches as well.

Qphoria wrote:He told me he is waiting at least 1 month between releases

I don't really think the big problem is the release frequency, it's when you release 1.5.1 a month after 1.5.0 and it has a whole new way of handling module data. I have no problem with bug fix only releases coming out in rapid succession that's going to happen on a new major version you'll have all known bugs fixed and release then new bugs will pop up, and you fix them. That's not a big deal. Like from 1.5.0 to 1.5.0.5 upgrading to get the bug fixes was very easy.

i2Paq wrote:I wish that he would start using SVN-version branches as well.

branches are fine only if there is going to be continued support on that branch. Like 1.4.x is branched because it kept going. But 1.5.0.5 was the end of the 1.5.0.x versions.. That is what "tags" or "revisions" are for.

Qphoria wrote:

i2Paq wrote:I wish that he would start using SVN-version branches as well.

branches are fine only if there is going to be continued support on that branch. Like 1.4.x is branched because it kept going. But 1.5.0.5 was the end of the 1.5.0.x versions.. That is what "tags" or "revisions" are for.

Whatever you call it, we get told time and again that it is "fixed in SVN" but at the same time that same SVN is worked on for upcoming additions.
How the hell can a simple store owner find fixes for his issues in the SVN when he, at the same time, will get unfinished code and thus other issues as well?
I really would like to start using 1.5.1.2 when it comes out, but I probably have to turn to the SVN to get bug-fixes. I'm scarred as hell doing that and I'm not even a simple store owner.

I'm not one that gives negative comments, I always try to see it positive, but this is an issues / point that really pisses me of every time I'm hoping to start using a new release!
I really cannot understand why it is so hard to just get the next release out, split it in a 1.5.1.2 branch for fixing BUGS and use the other for working on 1.5.3 or whatever.

Just venting my frustration here but it looks so "unprofessional" saying you need to use the SVN but at the same time you know you cannot.

Xsecrets wrote:

Johnathan wrote: (The good news is that Daniel mentioned this in his last update to the future of OpenCart, so we may finally be getting a more stable release schedule in the future.)

which post was this? I don't recall him talking about this in a while. I know before 1.5 was released he seemed like he had bended to the idea of structuring releases better, but I haven't seen anything like that since 1.5 came out.

http://forum.opencart.com/viewtopic.php ... 46#p183829

He says, "i think then i will leave it a while and let the extensions all ready released catch up and just fix bugs when they come up." Maybe that was just my interpretation.

Johnathan wrote:

Xsecrets wrote:

Johnathan wrote: (The good news is that Daniel mentioned this in his last update to the future of OpenCart, so we may finally be getting a more stable release schedule in the future.)

which post was this? I don't recall him talking about this in a while. I know before 1.5 was released he seemed like he had bended to the idea of structuring releases better, but I haven't seen anything like that since 1.5 came out.

http://forum.opencart.com/viewtopic.php ... 46#p183829

He says, "i think then i will leave it a while and let the extensions all ready released catch up and just fix bugs when they come up." Maybe that was just my interpretation.

I must have missed that one. It also must be nice to be able to hire people to give away free support.

i2Paq wrote:

Qphoria wrote:

i2Paq wrote:I wish that he would start using SVN-version branches as well.

branches are fine only if there is going to be continued support on that branch. Like 1.4.x is branched because it kept going. But 1.5.0.5 was the end of the 1.5.0.x versions.. That is what "tags" or "revisions" are for.

Whatever you call it, we get told time and again that it is "fixed in SVN" but at the same time that same SVN is worked on for upcoming additions.
How the hell can a simple store owner find fixes for his issues in the SVN when he, at the same time, will get unfinished code and thus other issues as well?
I really would like to start using 1.5.1.2 when it comes out, but I probably have to turn to the SVN to get bug-fixes. I'm scarred as hell doing that and I'm not even a simple store owner.

I'm not one that gives negative comments, I always try to see it positive, but this is an issues / point that really pisses me of every time I'm hoping to start using a new release!
I really cannot understand why it is so hard to just get the next release out, split it in a 1.5.1.2 branch for fixing BUGS and use the other for working on 1.5.3 or whatever.

Just venting my frustration here but it looks so "unprofessional" saying you need to use the SVN but at the same time you know you cannot.

But I think you just aren't understanding what a "revision" or "tag" is.. Granted, daniel should list the revision that the fix is in.. But if you find a bug in 1.5.0.5 and he has already released 1.5.1.1 and that bug still exists... he will fix it in the latest version.. and that file might also have some 1.5.1.1 only code.. he isn't going to maintain a separate 1.5.0.5 branch and fix it in 2 places.

That is why it is more important that releases do not break the existing API functionality so that upgrades aren't so scary. That is the real issue. I think we need to start looking at things from an upgrade standpoint, whereas daniel looks at each release as a new release and doesn't necessarily think about coming from the previous version which is the cause for much of the breakage. At the same time he wants to add new features and things that he wished he would have added earlier.... so its a difficult balance to achieve.

But a branch is only good if someone is going to maintain a separate branch of code and fixes.. that isn't going to happen for a point release. But if daniel can list which rev has the fix, you can check what files were changed in that update and grab only those files by revision from svn and merge applicable changes into your code.

Qphoria wrote: But I think you just aren't understanding what a "revision" or "tag" is.. Granted, daniel should list the revision that the fix is in.. But if you find a bug in 1.5.0.5 and he has already released 1.5.1.1 and that bug still exists... he will fix it in the latest version.. and that file might also have some 1.5.1.1 only code.. he isn't going to maintain a separate 1.5.0.5 branch and fix it in 2 places.

That is why it is more important that releases do not break the existing API functionality so that upgrades aren't so scary. That is the real issue. I think we need to start looking at things from an upgrade standpoint, whereas daniel looks at each release as a new release and doesn't necessarily think about coming from the previous version which is the cause for much of the breakage. At the same time he wants to add new features and things that he wished he would have added earlier.... so its a difficult balance to achieve.

But a branch is only good if someone is going to maintain a separate branch of code and fixes.. that isn't going to happen for a point release. But if daniel can list which rev has the fix, you can check what files were changed in that update and grab only those files by revision from svn and merge applicable changes into your code.

well the problem is all the changes Daniel does. Once a version is released there should be no new features or API changes till the next major version. That way you put the released version into bug fix mode and simply develop on the new version. Yes it makes it a pain you have to fix bugs in two places, but this is the way it should be done. As it is you get a report that the bug is fixed in svn, but that does you absolutely no good because svn also is packed with new features and possibly api changes so you can't just pull that fix. Honestly 1.5.0.x should have all been RC's and 1.5.1 should have been the official release. That's the other part of the problem. Now you have 1.5.0.x which is basically just going to be abandoned. Daniel isn't touching it, and I know any future mods I write won't work on it, because if I'm writing a new mod I'm not going to bother writing it for two versions particularly when 1.5.0.x was so short lived.