|

»

Automatic version checking is now in Gallery 3

View: New views

6 Messages — Rating Filter: Alert me

	Automatic version checking is now in Gallery 3 by Bharat Mediratta :: Rate this Message: \| View Threaded \| Show Only this Message [this info should find a home on the wiki somewhere, Dave/Kevin/CK can you slot this in somewhere and clean it up a bit?] --- I've added automatic version checking to Gallery 3.0.1, and here's how it works. There are a few moving parts so I'll diagram it out as best I can. Each Gallery 3 install now has a new file called ".build_number". This contains a number that only increases and lets you know the "build" that you have for a particular branch. Every time you do a "git pull" or get a new snapshot, you're going to see this number go up. After you get the latest code and upgrade when you go to Admin > Dashboard you'll see a new block that tells you exactly which version of Gallery you're using and what build it is. The build is drawn from the .build_number file. There's a "check now" button and when you click on that, the Gallery install contacts gallery.menalto.com and gets info about what versions are available. We don't send any information about your install back to the server with this request! As best we can, this is all one way traffic from the Gallery website down to your Gallery install. The gallery website has a version checking service called "versioncheck" that we've been using for years. If you go to this url: http://gallery.menalto.com/versioncheck/gallery3 It lists version and build info for the official release and each development branch. When Gallery notices that the build number has gone up on your development branch, or that the release version has gone up, it'll notify you and give you links to upgrade or be reminded later. By default, this checking happens automatically once a week. You can disable the automatic checking at Admin > Dashboard. We want automatic checking on by default though because we strongly want to encourage users to stay current. Behind the scenes there's some tricky bits in getting the .build_number file to be updated. Unlike subversion and other centralized revision control systems, git has no single version number. So to get the .build_number file to have an ever-increasing number, I'm running an automated script that scans for changes in any of the branches (currently it's only looking at 3.0.x and master) and bumps the .build_number when sees a change. It also bumps the versioncheck number in the database. When you do an upgrade, we automatically clear the version check string in your Gallery 3 install assuming that you have the latest code. So if you're a git user and you do "git pull", it will get cleared when you run "php index.php upgrade" (which you should be running after you do git pull anyway). Thoughts/comments welcome. -Bharat ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Automatic version checking is now in Gallery 3 by Andy Staudacher-3 :: Rate this Message: \| View Threaded \| Show Only this Message On Mon, Jan 17, 2011 at 8:04 PM, Bharat Mediratta <bharat@...> wrote: [...] Behind the scenes there's some tricky bits in getting the .build_number file to be updated. Unlike subversion and other centralized revision control systems, git has no single version number. So to get the .build_number file to have an ever-increasing number, I'm running an automated script that scans for changes in any of the branches (currently it's only looking at 3.0.x and master) and bumps the .build_number when sees a change. It also bumps the versioncheck number in the database. Some clarification might be needed. Does the .build_number go up o n any git commit or only on every official public released version? Different question: For people who are on a release (=non-development) branch, and actually just care about well QA'ed changes and security fixes, do they get a "you're not using a current version" notification on ever git commit / merge to the master branch? In other words: Most Gallery 3 users care about pressing security fixes and well QA'ed bug fixes. I don't think they want to track branch_master_build_number, but instead, they want to track the released_build_number or something like that. Or do you intend to adopt a model like Google Chrome's where you roll out an update to a certain percentage of users to see whether everything works fine, and then promote the update to everyone else? Also: Good to see .build_number access requested to everyone (.htaccess). :) Cheers, - Andy When you do an upgrade, we automatically clear the version check string in your Gallery 3 install assuming that you have the latest code. So if you're a git user and you do "git pull", it will get cleared when you run "php index.php upgrade" (which you should be running after you do git pull anyway). Thoughts/comments welcome. -Bharat ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ] ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Automatic version checking is now in Gallery 3 by Bharat Mediratta :: Rate this Message: \| View Threaded \| Show Only this Message On 1/17/11 10:54 PM, Andy Staudacher wrote: > On Mon, Jan 17, 2011 at 8:04 PM, Bharat Mediratta <bharat@... > <mailto:bharat@...>> wrote: > > [...] > > Behind the scenes there's some tricky bits in getting the .build_number > file to be updated. Unlike subversion and other centralized revision > control systems, git has no single version number. So to get the > .build_number file to have an ever-increasing number, I'm running an > automated script that scans for changes in any of the branches > (currently it's only looking at 3.0.x and master) and bumps the > .build_number when sees a change. It also bumps the versioncheck number > in the database. > > > Some clarification might be needed. Does the .build_number go up o n any > git commit or only on every official public released version? Every 30 minutes the automated process bumps the build number if there have been any non-build-number changes. > Different question: For people who are on a release (=non-development) > branch, and actually just care about well QA'ed changes and security > fixes, do they get a "you're not using a current version" notification > on ever git commit / merge to the master branch? > > In other words: Most Gallery 3 users care about pressing security fixes > and well QA'ed bug fixes. I don't think they want to > track branch_master_build_number, but instead, they want to track > the released_build_number or something like that. > > Or do you intend to adopt a model like Google Chrome's where you roll > out an update to a certain percentage of users to see whether everything > works fine, and then promote the update to everyone else? If you're using a release version, you'll only be notified when there's a new official release. Basically, whatever type of file you downloaded (official release, zipball from a branch, git pull) we'll tell you when there's further development along that line, but we won't notify you for stuff that happens on other lines. Theoretically if you track master, you want the latest stuff. If you switch to a branch (eg: 3.0.x) then you'll keep getting notified about new developments on 3.0.x. When we release 3.0.1, you'll get that and then you'll get any further changes on the path to 3.0.2, etc. One tricky bit I need to sort out is what happens when we bump the 3.0.x branch to have info about the 3.0.1 release. At that point we're going to temporarily mark the branch as a "release" which means that anybody who gets that code is only going to get notified when there's a new release. We might have to branch 3.0.x -> 3.0.1 at that point.. not sure about that. Maybe we'll just keep the window really small there. > Also: Good to see .build_number access requested to everyone (.htaccess). :) I can't quite parse that, so I'm assuming you mean "glad to see that .build_number access is _denied_ to everyone in .htaccess" :-) That only takes effect if you uncomment that block in your .htaccess of course :-/ -Bharat ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Automatic version checking is now in Gallery 3 by Andy Staudacher-3 :: Rate this Message: \| View Threaded \| Show Only this Message On Mon, Jan 17, 2011 at 11:12 PM, Bharat Mediratta <bharat@...> wrote: On 1/17/11 10:54 PM, Andy Staudacher wrote: > On Mon, Jan 17, 2011 at 8:04 PM, Bharat Mediratta <bharat@... > <mailto:bharat@...>> wrote: > > [...] Theoretically if you track master, you want the latest stuff. If you switch to a branch (eg: 3.0.x) then you'll keep getting notified about new developments on 3.0.x. When we release 3.0.1, you'll get that and then you'll get any further changes on the path to 3.0.2, etc. Great. One tricky bit I need to sort out is what happens when we bump the 3.0.x branch to have info about the 3.0.1 release. At that point we're going to temporarily mark the branch as a "release" which means that anybody who gets that code is only going to get notified when there's a new release. We might have to branch 3.0.x -> 3.0.1 at that point.. not sure about that. Maybe we'll just keep the window really small there. Is this a new problem? Sounds very similar to the upgrade paths we maintained for G2. > Also: Good to see .build_number access requested to everyone (.htaccess). :) I can't quite parse that, so I'm assuming you mean "glad to see that .build_number access is _denied_ to everyone in .htaccess" :-) Indeed, I meant to write s/requested/denied/ :) That only takes effect if you uncomment that block in your .htaccess of course :-/ -Bharat ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Automatic version checking is now in Gallery 3 by Chris Kelly-2 :: Rate this Message: \| View Threaded \| Show Only this Message http://codex.gallery2.org/Gallery3:Automatic_version_checking Appears on http://codex.gallery2.org/Category:Gallery_3 On Jan 17, 2011, at 11:04 PM, Bharat Mediratta wrote: [this info should find a home on the wiki somewhere, Dave/Kevin/CK can you slot this in somewhere and clean it up a bit?] --- I've added automatic version checking to Gallery 3.0.1, and here's how it works. There are a few moving parts so I'll diagram it out as best I can. Each Gallery 3 install now has a new file called ".build_number". This contains a number that only increases and lets you know the "build" that you have for a particular branch. Every time you do a "git pull" or get a new snapshot, you're going to see this number go up. After you get the latest code and upgrade when you go to Admin > Dashboard you'll see a new block that tells you exactly which version of Gallery you're using and what build it is. The build is drawn from the .build_number file. There's a "check now" button and when you click on that, the Gallery install contacts gallery.menalto.com and gets info about what versions are available. We don't send any information about your install back to the server with this request! As best we can, this is all one way traffic from the Gallery website down to your Gallery install. The gallery website has a version checking service called "versioncheck" that we've been using for years. If you go to this url: http://gallery.menalto.com/versioncheck/gallery3 It lists version and build info for the official release and each development branch. When Gallery notices that the build number has gone up on your development branch, or that the release version has gone up, it'll notify you and give you links to upgrade or be reminded later. By default, this checking happens automatically once a week. You can disable the automatic checking at Admin > Dashboard. We want automatic checking on by default though because we strongly want to encourage users to stay current. Behind the scenes there's some tricky bits in getting the .build_number file to be updated. Unlike subversion and other centralized revision control systems, git has no single version number. So to get the .build_number file to have an ever-increasing number, I'm running an automated script that scans for changes in any of the branches (currently it's only looking at 3.0.x and master) and bumps the .build_number when sees a change. It also bumps the versioncheck number in the database. When you do an upgrade, we automatically clear the version check string in your Gallery 3 install assuming that you have the latest code. So if you're a git user and you do "git pull", it will get cleared when you run "php index.php upgrade" (which you should be running after you do git pull anyway). Thoughts/comments welcome. -Bharat ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ] ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]
	Re: Automatic version checking is now in Gallery 3 by Bharat Mediratta :: Rate this Message: \| View Threaded \| Show Only this Message Thanks, CK! On 01/18/11 16:27, Chris Kelly wrote: > http://codex.gallery2.org/Gallery3:Automatic_version_checking > > <http://codex.gallery2.org/Gallery3:Automatic_version_checking>Appears on > > http://codex.gallery2.org/Category:Gallery_3 > <http://codex.gallery2.org/Category:Gallery_3> > On Jan 17, 2011, at 11:04 PM, Bharat Mediratta wrote: > >> [this info should find a home on the wiki somewhere, Dave/Kevin/CK can >> you slot this in somewhere and clean it up a bit?] >> --- >> >> I've added automatic version checking to Gallery 3.0.1, and here's how >> it works. There are a few moving parts so I'll diagram it out as best I >> can. >> >> Each Gallery 3 install now has a new file called ".build_number". This >> contains a number that only increases and lets you know the "build" that >> you have for a particular branch. Every time you do a "git pull" or get >> a new snapshot, you're going to see this number go up. >> >> After you get the latest code and upgrade when you go to Admin > >> Dashboard you'll see a new block that tells you exactly which version of >> Gallery you're using and what build it is. The build is drawn from the >> .build_number file. There's a "check now" button and when you click on >> that, the Gallery install contacts gallery.menalto.com >> <http://gallery.menalto.com> and gets info >> about what versions are available. We don't send any information about >> your install back to the server with this request! As best we can, this >> is all one way traffic from the Gallery website down to your Gallery >> install. >> >> The gallery website has a version checking service called "versioncheck" >> that we've been using for years. If you go to this url: >> >> http://gallery.menalto.com/versioncheck/gallery3 >> >> It lists version and build info for the official release and each >> development branch. When Gallery notices that the build number has gone >> up on your development branch, or that the release version has gone up, >> it'll notify you and give you links to upgrade or be reminded later. >> >> By default, this checking happens automatically once a week. You can >> disable the automatic checking at Admin > Dashboard. We want automatic >> checking on by default though because we strongly want to encourage >> users to stay current. >> >> Behind the scenes there's some tricky bits in getting the .build_number >> file to be updated. Unlike subversion and other centralized revision >> control systems, git has no single version number. So to get the >> .build_number file to have an ever-increasing number, I'm running an >> automated script that scans for changes in any of the branches >> (currently it's only looking at 3.0.x and master) and bumps the >> .build_number when sees a change. It also bumps the versioncheck number >> in the database. >> >> When you do an upgrade, we automatically clear the version check string >> in your Gallery 3 install assuming that you have the latest code. So if >> you're a git user and you do "git pull", it will get cleared when you >> run "php index.php upgrade" (which you should be running after you do >> git pull anyway). >> >> Thoughts/comments welcome. >> -Bharat >> >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> __[ g a l l e r y - d e v e l ]_________________________ >> >> [ list info/archive --> http://gallery.sf.net/lists.php ] >> [ gallery info/FAQ/download --> http://gallery.sf.net ] > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ]