Post by Qphoria » Mon Mar 05, 2012 12:39 pm

OpenCart SVN up to this point has been loosely used as a trunk only repo.
2012-03-04_2240.png

2012-03-04_2240.png (3.13 KiB) Viewed 5127 times

This means anytime changes were made, it was pushed into the trunk.
This is fine for bug fixes, but breaks lots of things when new features are being added for the next version that are not compatible with the current release version. The method we used was considered an "unstable trunk" method, which means the SVN trunk was never to be considered the latest "stable" release. It was just a mish-mash of bug fixes and new features, all thrown together.

So here are some plans to make the process a bit smarter so that people can get the latest bug fix version of the code that is compatible with their release version, without getting the new features of the future unstable version.

Plan A: I initially talked about switching to a "stable trunk" after 1.5.2 was released so that any bug fixes for the current "release" version would be pushed to the trunk, while any new features for 1.5.3 would be in its own development branch. Then when ready, the branch would be merged into the trunk.
2012-03-04_2225.png

2012-03-04_2225.png (5.67 KiB) Viewed 5128 times

But after thinking about it, this may not be the smartest method because it means only people using the latest release version could get bug fixes for their version.


Plan B: Another option is to branch each version as bug fix only branches so that any bugs found for that version could be committed to that specific branch. This makes more sense as it allows different versions to have their own bug fixes.
2012-03-04_2229.png

2012-03-04_2229.png (5 KiB) Viewed 5128 times

I would be the one to maintain the bug fix branch while daniel worked on the dev trunk. Basically any bugs in the bug thread for that version that are fixed in dev, I would backport to the current version, extracting any new features. I will have to hope daniel communicates with me when he finds a bug fix, and checks bug fixes in separately from new features to make it easier to back port revisions. This means it would still be an unstable trunk, but each version would be branched out for its own bug fixes so the end goal is much more expanded and users can simply update by their respective branch instead of trunk.

I think this is a better way to go, at least for now.


In related news, I have the PHP SVN class working with opencart's repo and will be releasing it as a module for 1.5.2 in a few weeks when its ready. The php svn class works quite well and is more or less the equivalent to file_get_contents where the file is in the repository. I am setting it up so that I can simply say "update to r910" and you simply enter "910" in the box and click "update" and it will update all the files on your site with those from that revision.

This has the potential to make upgrades unbelievably easy, by simply entering the revision of the repository you want to be at. You won't need to know anything about SVN or be a developer. Just enter a simple number.

This means that you will all want to be diligent about using vQmod for your core changes, so that svn updates do not blow away your changes. I do have plans to add in an autobackup of files that get updated, but that is for version 2.0 down the road.

But this can mean the end of 1.5.x.1 builds. We can release a version with a few tiny bugs and then have the svn update check automatically daily when you login to admin. It will alert you that there are bug fixes and you can simply click "update latest fixes".

The php svn class also has budding support for patch files. But at this time they are not working.

Comments or Questions?

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Renato Frota » Mon Mar 05, 2012 2:44 pm

I do not like the idea of having "multiple stables". It makes me remember Joomla, currently 1.5, 1.7 and 2.5 versions. They still have not only themes, but also components and modules being developed to 1.5. However, I do not see a reason for start a website with 1.5 today, if they have a newer version...

I successfully upgraded 4 stores from 1.4.x to 1.5.1.3, no-vQmod modifications are very rare now! Extensions are upgradeable (here in the forum some material is available to help with this).

I think anybody who start a 1.5.0 (or older) today is looking for specific mods, not upgraded to 1.5.1.3/1.5.2 yet. Then, developing multiple versions only makes sense for me if you will continue to provide ways to upgrade, then new changes to older cores being strictly bugfixes only.

Sorry my english.

New member

Posts

Joined
Wed Aug 31, 2011 1:21 pm

Post by i2Paq » Mon Mar 05, 2012 3:16 pm

The initial idea of having a so called Stable trunk is the way to go for me.

Will you soon to be released Auto-update for OpenCart work with plan A and Plan B or only with plan B?

Norman in 't Veldt
Moderator OpenCart Forums

_________________ READ and Search BEFORE POSTING _________________

Our FREE search: Find your answer FAST!.

[How to] BTW + Verzend + betaal setup.


User avatar
Global Moderator

Posts

Joined
Mon Nov 09, 2009 7:00 pm
Location - Winkel - The Netherlands

Post by Qphoria » Tue Mar 06, 2012 12:02 am

You guys seem to be missing the point.

It isn't multiple stables.. it is a stable for the current version. When a new version is released, then the branch for the previous release stops getting updates. As I said, having a stable trunk is limiting when people with 1.5.1.3 are not having any problems or have already patched their stores and don't need any of the new 1.5.2 features or changes.

You guys are what we call "professional upgraders".. always waiting to be on the bleeding edge which as you can see causes more harm than good when you jump on too early. Most professional stores don't feel the need to upgrade every time a new release is out, but they do need the handful of bug fixes for their version. With the multiple branch method, then people who have 1.5.1.3 simply won't need to make all the bug fixes manually.

To you, nothing changes. You will just point your svn to the trunk like always
For others that want bug fixes for their current version, they will simply be able to point their svn to the branch that matches their version, allowing them to get only the few files that have bug fixes and don't break their sites with new features from future trunk versions

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Renato Frota » Tue Mar 06, 2012 2:17 am

Qphoria wrote:You guys seem to be missing the point.

It isn't multiple stables.. it is a stable for the current version. When a new version is released, then the branch for the previous release stops getting updates. As I said, having a stable trunk is limiting when people with 1.5.1.3 are not having any problems or have already patched their stores and don't need any of the new 1.5.2 features or changes.

You guys are what we call "professional upgraders".. always waiting to be on the bleeding edge which as you can see causes more harm than good when you jump on too early. Most professional stores don't feel the need to upgrade every time a new release is out, but they do need the handful of bug fixes for their version. With the multiple branch method, then people who have 1.5.1.3 simply won't need to make all the bug fixes manually.

To you, nothing changes. You will just point your svn to the trunk like always
For others that want bug fixes for their current version, they will simply be able to point their svn to the branch that matches their version, allowing them to get only the few files that have bug fixes and don't break their sites with new features from future trunk versions
I got the point. Fully agree with you now.

New member

Posts

Joined
Wed Aug 31, 2011 1:21 pm

Post by Johnathan » Tue Mar 06, 2012 2:27 am

Qphoria wrote:In related news, I have the PHP SVN class working with opencart's repo and will be releasing it as a module for 1.5.2 in a few weeks when its ready. The php svn class works quite well and is more or less the equivalent to file_get_contents where the file is in the repository. I am setting it up so that I can simply say "update to r910" and you simply enter "910" in the box and click "update" and it will update all the files on your site with those from that revision.
This would be awesome, and with vQmod, would make updating a snap.

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by KenHas » Wed Mar 07, 2012 1:26 am

then the branch for the previous release stops getting updates
For others that want bug fixes for their current version
The updates (like new features) stop but the bugfixes keep coming ?

If so, won't this be difficult to keep track (as a programmer)? There will have to be a lot more testing and stuff. Now you test fixes on the latest version and that's it (to keep it simple).

Example: version 1 is being widly used. Version 2 released, major change in the checkout part. Version 3, major change in registration part.

If someone finds a bug in the checkout part of version 3, you would have to make sure the bug isn't present in the previous 2 versions. And make sure the bugfix doesn't turn the previous versions broken.

Simple example, I know. Just trying to explain something in my head O0

Newbie

Posts

Joined
Wed Oct 05, 2011 5:52 pm

Post by Qphoria » Wed Mar 07, 2012 2:49 am

Let me give an example

This is what currently happens:
1. We Release version 1.5.1.3 as a zip
2. Bugs are found over the next few weeks
3. These bug fixes get added to the SVN TRUNK
4. 3 weeks goes by and Daniel decides "I'm going to make an order editor for 1.5.2"
5. He starts making changes for that and adding them to SVN TRUNK as well as other bug fixes.

Now, if you have 1.5.1.3 and get the latest SVN TRUNK update, you have broken code that is meant for 1.5.2
Now your 1.5.1.3 doesn't work right.


With my proposed method:
1. We Release version 1.5.2 as a zip
2. Bugs are found over the next few weeks
3. These bug fixes get added to the SVN TRUNK
4. 3 weeks goes by and Daniel decides "I'm going to redesign checkout for 1.5.3"
5. We "Branch" 1.5.2 bug fixes to the "1.5.2" BRANCH
6. He starts making changes for that and adding them to SVN TRUNK

Now you have 1.5.2 and want the latest bug fixes. So instead of pointing to the SVN TRUNK
You simply point to the 1.5.2 BRANCH. That ensures you won't get any of the new features meant for 1.5.3 that would break 1.5.2 code.

That's it.. its mostly transparent to you. The only change you make is changing your repository to point to the branch for the current version you have instead of the trunk.

Now when 1.5.3 comes out, bug fixes for 1.5.2 will stop because by that point most of them should have been found and they will already be in the 1.5.3 version. And then 1.5.3 gets branched and bug fixes start being made for that version.. and so on and so on.



If you don't know what SVN is, that is fine too. When I get the phpsvn updater working, even non-techies can simply click "update" to get the latest bug fixes for their version of opencart.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Wed Mar 07, 2012 5:48 am

I think it's a great idea that's really going to push OpenCart popularity. It's going to require a lot more discipline for versioning than OpenCart has had though. If this system had exited in the past we would have had stuff like a 1.5.1.1 branch and 1.5.1.2 branch which would definitely be confusing to people.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by uksitebuilder » Wed Mar 07, 2012 7:14 am

I think it's bang on the money apart from bug fixes for the previous versions stopping for all but the top branch and the trunk
Qphoria wrote:Now when 1.5.3 comes out, bug fixes for 1.5.2 will stop because by that point most of them should have been found and they will already be in the 1.5.3 version. And then 1.5.3 gets branched and bug fixes start being made for that version.. and so on

User avatar
Guru Member

Posts

Joined
Thu Jun 09, 2011 11:37 pm
Location - United Kindgom

Post by ccM » Wed Mar 07, 2012 10:14 am

Sounds fantastic Qphoria!!! Exactly what I wanted to hear 8) The current upgrade procedure is so time consuming trying to find all of the bug fixes and avoid the new features that aren't commented. Double thumbs up.

ccM
New member

Posts

Joined
Fri Aug 19, 2011 6:51 am
Location - QLD, Australia

Post by wroughtec » Wed Mar 07, 2012 8:50 pm

All sounds good just one question though.

Are the current changes being made to the SVN (ie post 1.5.2) using your above method or is it still to be implemented ie just bug fixes.

Or in another way how stable or unstable should we consider the current trunk?

New member

Posts

Joined
Sat Feb 18, 2012 7:45 am

Post by i2Paq » Thu Mar 08, 2012 5:05 am

Yep, that convinced me to!

Norman in 't Veldt
Moderator OpenCart Forums

_________________ READ and Search BEFORE POSTING _________________

Our FREE search: Find your answer FAST!.

[How to] BTW + Verzend + betaal setup.


User avatar
Global Moderator

Posts

Joined
Mon Nov 09, 2009 7:00 pm
Location - Winkel - The Netherlands

Post by Qphoria » Thu Mar 08, 2012 5:20 am

uksitebuilder wrote:I think it's bang on the money apart from bug fixes for the previous versions stopping for all but the top branch and the trunk
Qphoria wrote:Now when 1.5.3 comes out, bug fixes for 1.5.2 will stop because by that point most of them should have been found and they will already be in the 1.5.3 version. And then 1.5.3 gets branched and bug fixes start being made for that version.. and so on
well realistically by the time 1.5.3 is out, all if not most of the "actual" bugs would have long since been discovered and fixed. Take 1.5.1.3 for example.. most of the real bugs are found in the first 3 weeks... with a few stragglers here and there. As it is now, people are pretty much stuck sniffing through the bug thread and fixing the bugs themselves.

At least with this way, I will be doing all the work and you can simply get the latest update for the life of the version. Any bugs found in the previous release after the new release... you will simply be on your own for... but it is highly unlikely that you will find any.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Thu Mar 08, 2012 5:23 am

wroughtec wrote:All sounds good just one question though.

Are the current changes being made to the SVN (ie post 1.5.2) using your above method or is it still to be implemented ie just bug fixes.

Or in another way how stable or unstable should we consider the current trunk?
So right now, trunk has all the latest bug fixes only.
Right after a new release, a week or two is spent just on bug fixes. So use the trunk for now.
When daniel is ready to start making new changes for 1.5.3, I will branch that last version to 1.5.2 (there is one already but you shouldn't use it yet) and I will be in charge of continued bug fix updates. Daniel will operate in business-as-usual mode. The only person with a new job is me.

I'm working on an automatic update system and looking to put it into the admin area as well as the installer and upgrade steps, so that even when you first download it, it will check for updates from the "update server"

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by marvmen21 » Thu Mar 08, 2012 11:32 am

This sounds great Q! This will be definitely a major improvement to the current Opencart upgrade & bug fixing system.

You want to thank me for my time! :) Click here to donate


Active Member

Posts

Joined
Tue Nov 09, 2010 4:54 am

Post by AvanOsch » Thu Mar 15, 2012 9:57 pm

Excellent!
I'm just starting to play around with Subversion, and your proposal sounds great!

However...
I have made some Extensions that do require core-changes.
Would it be possible to add "extension updaters" that take care of updating the extensions?
These "extension updaters" should of course be made/maintained by the person who released the Extension, and run after updating to another revision.

Thinking about it, this would also go for vQMod extensions... (as they too can have changes because of core-updates)

Just an idea...

(It would be totally insane if the update script checks for extensions, and then checks for "updaters" to those extensions!)

User avatar
Active Member

Posts

Joined
Sat Sep 03, 2011 9:17 pm

Post by Qphoria » Thu Mar 15, 2012 10:14 pm

AvanOsch wrote: However...
I have made some Extensions that do require core-changes.
Would it be possible to add "extension updaters" that take care of updating the extensions?
These "extension updaters" should of course be made/maintained by the person who released the Extension, and run after updating to another revision.

Thinking about it, this would also go for vQMod extensions... (as they too can have changes because of core-updates)

Just an idea...

(It would be totally insane if the update script checks for extensions, and then checks for "updaters" to those extensions!)
Don't know what you mean. As you said it is up to the extension maker to handle updates. What does that have to do with the core?

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by AvanOsch » Fri Mar 16, 2012 2:09 am

Qphoria wrote: Don't know what you mean. As you said it is up to the extension maker to handle updates. What does that have to do with the core?
Simply said:
Something like an update script that the extension maker can make, that automatically gets included when updating the core.
[EDIT]
The user would need to put the updates for their extensions in place before running the core update in this case.

And with the "totally insane" statement I was thinking of vQmod extensions (which can be detected)
If found, an auto search for the extension update (matching revisions or whatnot)
This would mean a full update, including extensions...

User avatar
Active Member

Posts

Joined
Sat Sep 03, 2011 9:17 pm

Post by Qphoria » Fri Mar 16, 2012 3:05 am

Ah I see... Thats starts to get into a lot of "callhome" stuff then which can potentially get messy. The main problem is that right now not all mods are stored in one structured area that the "updater" could parse through and compare.

As an alternative.. and this is something I've already started added to my mods.. would be an update check on each mod that fires off when it is opened in the admin and determines if there is an update and allows you to one-click update it right from the admin. That is of course entirely dependent on the mod author to support on their own respective servers to do and only checks when you actually edit the page so that their own code loads.

Perhaps if the core had this check done on the list page or even the main admin dashboard.. that would be sufficient. Then it could check each extension for the "checkForUpdate()" function.. if it exists, call it and return back the result. Tho that would still require a more structured storage format or at least reporting format.

it is something to think about.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 31 guests