Closed Bug 185436 Opened 19 years ago Closed 14 years ago
Software update for release builds
26.42 KB, application/octet-stream
28.99 KB, patch
|Details | Diff | Splinter Review|
10.00 KB, application/zip
15.35 KB, patch
|Details | Diff | Splinter Review|
29.33 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021120 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021120 Chimera/0.6+ Apple's Software Update application works only with Mac OS X and Apple's components. It does not work for all the third-party software you install yourself. All these components, software, shareware and freeware you install yourself are not checked by Apple's Software Update application. AlphaOmega Software developed a more global application: Extended Software Updater. From a user's point of view, it is as simple to use as Apple's Software Update application, provides the same functionnality, but does not limit to Apple's components and can work with all your other third-party software. From a developer or editor's point of view, it is very simple to make an application compatible with Extended Software Updater (only 2 text files are necessary) and make users benefit from it. Read the whole documentation for more details on the URL linked with this request. Reproducible: Always Steps to Reproduce: Only one small text file needs to be added to the application bundle and one small text file put on the Chimera site to add full compatibility for this great software updating app.. I have already generated the two text files for adding to v.6. Only minor changes need be made to the version.txt file that would be posted to the chimera website for each release (version # and new feature description only).. Not a big effort really and a nice convenience for Chimera users who don't live 24/7 on Version Tracker to track all their apps.. :) I added the Updater.esud file to the Navigator bundle and the software updater instantly picked up on it.. now if someone in authority can check the file into the tree, and add the version.txt file to the website (as the URL is spelled out in the Updater.eusd file), then it's done already!
This file goes into the application bundle.
Would need to be placed on the Chimera website to be read by the updater application checking for new versions. It would be expected to be found at the URL: http://www.mozilla.org/projects/chimera/version.txt (The URL for this file is changeable. It can be changed in the Updater.esud file to indicate another URL if need be.)
A tiny nice update mechanism would be cool, but I don't like the idea of a proprietary, non-Apple software for that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree with Soren and what happen if they 'disappear', it's a "small french developer", privacy concerns also, no guarantee. With several friends, we made a similar request to Apple several months ago, to extend the check to non-apple products. We could perhaps wait to see if Apple will extend it. It's already the case for MSIE and StuffIt, but they are included in OSX.
Curios: What's the difference between update compatibility with non-Apple proprietary, and puttng a non-Apple proprietary update in the browser itself. In my view, the difference is (having over 400 applications in my apps drawer) I don't have to open each app, find and initiate an update check which usually doesn't even give you a direct link to download the new version nor a description of the changes. This way, only one app need be opened.. Hey, it works, it's available, it doesn't require waiting add infinitum on Apple's non response, and it doesn't really require any real programming. So if the outfit folded. not like it was a lot of work lost.. And for now, it's something you can do right away. No waiting on update manager programming and arguing over the method, the format, the x,y, and z as we've seen with other requests (like nixing tabs for something more Aqualike)..this is out there, free, works, and. what more could you ask for? As it is, Apple's playing favorites. IE for example is NOT Apple software nor part of the OS in any real aspect, yet Microsoft gets to use Apple's software update.. grrr. Lastly, would it really HARM anything to include compatibility since it's not a real effort or expenditure of time to do it?
Actually , I dont' know why it didn't hit me before.. all three concerns about EDU are patently false because they all relie on the premise of a "master version server".. which is not how this program works. I would encourage doubters to look more carefully at the information on ESU.. Q: What if the "small French developer goes belly-up?" A: Doesn't matter. Version #s are served by the website of the developer of each compatible application, not the french developer. Q: What about privacy and security? A: Why should this be a concernwith ESU? ESU is only activated when the user loads the ESU application. Beyond that, ESU only goes to website of each developer which has made a compatible application to check the posted current version file. Just like Windows update, it doens't share info with M$, Apple, or anyone else. It simply reads a text file with version # info. This could hardly be misconstrued as being a security hazard!
"Lastly, would it really HARM anything to include compatibility since it's not a real effort or expenditure of time to do it?" Write a patch (or get someone to do so) and it may be considered. Don't write a patch and this won't be fixed.
Arrghh.. I must be in a different chapter or book or something.. :) I had uploaded the patches with the initial report.. see the two textfiles.. the top file updater.esud is simply put into the application bundle before shipping it off to the net.. easy.. done.. voila! The other file, version.txt has to be placed on the developer page indicated within the first text file for it to be found. This is what ESU will look for when you click "check".. Someone with an ESU compatible copy of Chimera will see Navigator v.6 pop up in the ESU list.. When they click check, when it gets to Chimera, it will go to the developer page and compare the version file there (current) with the one on the user's disk.. (potentially outdated)..
What about 'SmartUpdate' ? http://mozilla.org/owners.html
That's pretty dead. Last checkin on Nov 6 1999 (see http://lxr.mozilla.org/mozilla/source/modules/softupdt ).
worth investigating since it's easy, but i don't think many people use it.
Assignee: saari → pinkerton
Target Milestone: --- → Camino1.0
Having a version check on cold launch would be nice, especially for those users that are not constantly looking for the latest releases. Juts a simple window: There is a new version of Camino available. A newer version of this software has just been detected, would you like to download it? (Never) (No) (Yes) That would be more than sufficiant for most of the people. And it would be really easy to implement using a shel script.
Summary: Add Extended Software Update application updater compatibility for release builds. → Application update for release builds.
*** Bug 283347 has been marked as a duplicate of this bug. ***
http://los.dtcurrie.net/code/ have a framework for just this. I will try to write a patch including this so that people can check it out.
Before you do so please make sure the licensing is compatable and useable with the mozilla public license.
(In reply to comment #15) > Before you do so please make sure the licensing is compatable and useable with > the mozilla public license. from the read me of the framework: "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE." would that work?
I have a better idea. How about we do what Colloquy currently does and just offer the box as Jasper suggested. We know it can be done (Colloquy did it!) so why not go the same route instead of using third-party software to accomplish this? This would be *excellent* for 09a1!
ben is working on a reimplementation of their update manager, we should be using that rather than something different. it should be done in time for ff1.1.
(Adding "software" to the description for easier searching)
Summary: Application update for release builds. → Application/Software update for release builds.
Apperantly OmniGroup has released a open source software update framework (called OmniSoftwareUpdate) which can be downloaded for free from their ftp site. I quickly looked over it and it provides a host of very usefull extra features I'm sure we'd all love to see in camino aswell. Including hardware and system checks for stats and such. It would be great if a developer could have a look at this. http://www.omnigroup.com/developer/sourcecode/
This won't make 1.0, retargeting for 1.1 per discussion with pink.
Target Milestone: Camino1.0 → Camino1.1
*** Bug 315816 has been marked as a duplicate of this bug. ***
Repost of https://bugzilla.mozilla.org/show_bug.cgi?id=322592#c37 Sorry I mis-read the bug title for #322592 originally -- It's probably worth pointing out the following update facility. Sparkle: http://www.andymatuschak.org/pages/sparkle Open-Source, Free (MIT License) From the website: Sparkle is a module that developers can stick in their Cocoa applications (five-step install!) to get instant self-update functionality. By that, I mean that your app will be able to update itself, not just check for new versions: it値l read the update information from an appcast on your server, download, extract, install, restart, and even offer to show the users release notes before they decide if they want to update.
We're planning on using the mozilla.org implementation of software update (which Firefox 1.5 uses) for this.
Attachment #109327 - Attachment is obsolete: true
Attachment #109329 - Attachment is obsolete: true
OS: Mac OS X 10.2 → Mac OS X 10.3
Assignee: mikepinkerton → nick.kreeger
Priority: -- → P2
Summary: Application/Software update for release builds → Software update for release builds
(In reply to comment #24) > We're planning on using the mozilla.org implementation of software update > (which Firefox 1.5 uses) for this. > Sparkle is almost the new standart for open-source mac apps. It's realy easy to set up (basically it's just a drag and drop + customization). Should be easier to add than the already existing mozilla.org SU-engine (I said should :p) so maybe it worths giving a shot ...
Sparkle was already mentioned above. Please don't comment in this bug unless you're working on the implementation of the mozilla.org update system into Camino. Thanks.
Whiteboard: [READ comment 27 BEFORE commenting]
Kicking to 1.2.
Target Milestone: Camino1.1 → Camino1.2
Setting priority per 1.6 roadmap.
Priority: P2 → P1
Blocker for a1 per meeting.
First-pass at an implementation; it still has at least one problem. This adds the framework to the build, adds a GUI pref to turn auto-check on and off, adds a menu-item for manual checking, and adds the necessary bits to default to auto-checking (every 24 hours). It builds a check URL dynamically that includes: OS version, Camino version, CPU architecture, and whether or not it's the International release, which I think covers everything we thought we would need to know. Notes: - This assumes sparkle is in the tree (bug 399977) - This does not address the EULA issue; I suggest we leave that for a follow-up bug, since we're not sure what the solution will be yet and it doesn't impact any of this code. - It assumes an update URL of https://caminobrowser.org/update-check just for the sake of putting something; we should figure out what the actual URL will be. - Most importantly, there's a build problem that I haven't been able to figure out: the framework copy stage is bound and determined to copy Sparkle.framework out of Camino's build directory, rather than the correct location of sparkle/build/Release/. Xcode knows where it lives, but I can't seem to teach the build step. Obviously I could add a skanky workaround in the form of a shell script to put it in the right place, but I'm hoping you can use your build-fu to tell me what I'm doing wrong. Anyone interested in testing this (you'll have to copy the build Sparkle.framework into the Camino build directory to work around the above), you can use: user_pref("app.update.url.override", "http://escapedthoughts.com/camino/update-test.rss"); which points to a dmg with no EULA and doctored to be version 9.9.
Assignee: nick.kreeger → stuart.morgan
Status: NEW → ASSIGNED
Attachment #285625 - Flags: review?(mark)
Comment on attachment 285625 [details] [diff] [review] fix, v1 I don't know what sparkle/ and sparke/build look like. How does this interact with objdir builds?
Badly (i.e., it ignores objdir); since I didn't want to muck with their build system, and it's a smallbuild, I just punted on that. Any thoughts on how to do that without forking their project (and without copying the entire tree, ideally)?
Where can I look at their tree?
Comment on attachment 285625 [details] [diff] [review] fix, v1 >Index: Info-Camino.plist.in > <key>mozProfileDirName</key> > <string>Camino</string> >+ <key>SUCheckAtStartup</key> >+ <false/> Nit: Apple's plist utilities output keys in order according to a case-sensitive sort, so the SU* entries should come before mozProfileDirName. (We used to be good about keeping things sorted in here, looks like we've kinda gotten a little bit lazy recently. Feel free to fix that here.) >Index: Makefile.in We really do this without support for objdirs. It'll totally screw with lots of things if we don't account for it, including universal builds. Where you currently have this: >+ ln -fs $(srcdir)/sparkle Let's do this: + mkdir -p sparkle + ln -fs $(ABS_topsrcdir)/camino/sparkle/* sparkle The rest of your patch should work as-is with only that change. > Index: src/preferences/PreferenceManager.mm >+ baseURL = [self getStringPref:"app.update.url" withSuccess:NULL]; It's still possible to end up without a baseURL here. What happens in that case? Should we just set manifestURL to @""? Will that avoid checking for updates while still leaving the user-facing prefs alone? I'm still going to look at your framework problem this afternoon, so hang tight for comments on that. In the future, could you use -U 8 on your diffs to give a little bit more context?
I wrote: >We really do this without support for objdirs. I meant that we really CAN'T do this without support for objdirs. :) In playing with your patch, I also found that my suggestion didn't quite work. We need to do this: mkdir -p sparkle ln -fs $(ABS_topsrcdir)/camino/sparkle/* sparkle rm -rf sparkle/Sparkle.xcodeproj rsync -aC $(ABS_topsrcdir)/camino/sparkle/Sparkle.xcodeproj sparkle Xcode actually follows the symlink to the xcodeproj and bases the location of the build directory on that, so we can live with symbolic links for everything except the xcodeproj.
Ugh, make that: mkdir -p sparkle rm -rf sparkle/Sparkle.xcodeproj ln -fs $(ABS_topsrcdir)/camino/sparkle/* sparkle rm -rf sparkle/Sparkle.xcodeproj rsync -aC $(ABS_topsrcdir)/camino/sparkle/Sparkle.xcodeproj sparkle Too bad ln has no "exclude" option.
Comment on attachment 285625 [details] [diff] [review] fix, v1 >Index: src/application/UserDefaults.h >+#define USER_DEFAULTS_UPDATE_INTERVAL_DEFAULT 86400 Use: #define USER_DEFAULTS_UPDATE_INTERVAL_DEFAULT (24 * 60 * 60) This patch looks good to me, with this comment and my previous comments addressed. I'll post a patch to handle the build stuff shortly.
Attachment #285625 - Flags: review?(mark) → review+
The first problem I found was that there was no proper dependency relationship set up, so nothing guaranteed that Sparkle would be built before anything that requires it. Stuart says that he set up the dependencies, but they must have gotten eaten along the way. I actually started with the current trunk pbxproj to build this one, since I wanted to try a few things out. The problem that Stuart mentioned in comment 32 about the Copy Frameworks phase not finding Sparkle.framework seems like an Xcode bug to me. To work around it, I've added a reference to Sparkle.framework in sparkle/build/Release in addition to the proxy reference that comes in from our inclusion of Sparkle.xcodeproj. The sparkle/build/Release/Sparkle.framework reference is only used for the two Copy Frameworks phases (Camino and CaminoStatic). We use the proxy reference from Sparkle.xcodeproj for the three link phases (Camino, CaminoStatic, and NavigationPrefPane). It's a little ugly, but it shouldn't hurt anything. This patch includes a safe change to mozilla/config/config.mk, to get it to pass an ARCHS argument to xcodebuild at all times. Currently, ARCHS is only passed for cross compilations, because it's assumed that none of the project files specify their own ARCHS and will thus default to building for the native architecture in the absence of ARCHS. Sparkle.xcode specifies i386 and ppc for its ARCHS, resulting in a universal build. This is not necessary in our build system, which expects to control its own single-architecture or cross-build stuff. This change to ARCHS is harmless for all other Xcode projects in the Mozilla tree. Everything is set up so that Sparkle always builds in Release mode. Stuart and I think that this is fine for us, since we push our compiler flags in from the make build system anyway. This patch also includes my suggested Makefile change to properly support objdir builds. I haven't tested this with CaminoStatic.
We should also talk about stripping non-English localizations from the framework we ship in the English-only version. Probably best left for a followup bug.
(In reply to comment #43) > We should also talk about stripping non-English localizations from the > framework we ship in the English-only version. Probably best left for a > followup bug. Follow the train to bug 401017 for that.
Comment on attachment 285627 [details] new general prefs nib Fix that tab chain!
Attachment #285627 - Flags: review-
(In reply to comment #32) > - This does not address the EULA issue; I suggest we leave that for a follow-up > bug, since we're not sure what the solution will be yet and it doesn't impact > any of this code. And to bug 401021 for that.
I've been talking with Andy a bit the last couple days trying to figure out that crasher in Sparkle (which is now fixed in trunk), and he says, for the record: me (23:58:42): Is there a compelling reason to use Sparkle 1.1 rather than the latest trunk? Andy (23:58:58): No. (23:59:04): You shouldn't. (23:59:06): It has known bugs. We may have our own compelling reasons, but I thought it was worth mentioning this here seeing as there hadn't been any discussion in this bug of what version of Sparkle we'd actually be using. Andy also says of the approximately 400 apps using Sparkle, about half are using 1.1, about one-fourth are using trunk, and about one-fourth are (still) using 1.0 or earlier. cl
You wanna tab chain? I got yer tab chain right here.
Attachment #286337 - Attachment mime type: application/octet-stream → application/zip
Comment on attachment 286337 [details] prefs nib, v2 I'd tighten up those bounding boxes a bit, but that's a preexisting problem.
Attachment #286337 - Flags: review?(mark) → review+
Addresses comments, doesn't include the build stuff that's now its own patch.
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle Awesome, thanks for figuring this out :)
Attachment #286337 - Flags: superreview?(mikepinkerton)
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle sr=pink
Attachment #286055 - Flags: superreview?(mikepinkerton) → superreview+
Comment on attachment 286337 [details] prefs nib, v2 rs=pink
Attachment #286337 - Flags: superreview?(mikepinkerton) → superreview+
Comment on attachment 286486 [details] [diff] [review] update code, v2 + NSString* manifestURL = !baseURL ? @"" : [NSString stringWithFormat:@"%@?os=%@&arch=%@&version=%@&intl=%d", do we also want to report a client-side UUID so we can count unique pings? sr=pink
Attachment #286486 - Flags: superreview?(mikepinkerton) → superreview+
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle We need both trunk and branch approval for the /config portion of this patch (everything else is within the /camino tree). Mento's explanation of this change is reproduced below; this should have *no impact whatsoever* for Firefox. (In reply to comment #42) > This patch includes a safe change to mozilla/config/config.mk, to get it to > pass an ARCHS argument to xcodebuild at all times. Currently, ARCHS is only > passed for cross compilations, because it's assumed that none of the project > files specify their own ARCHS and will thus default to building for the native > architecture in the absence of ARCHS. Sparkle.xcode specifies i386 and ppc for > its ARCHS, resulting in a universal build. This is not necessary in our build > system, which expects to control its own single-architecture or cross-build > stuff. This change to ARCHS is harmless for all other Xcode projects in the > Mozilla tree.
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle a=beltzner for after the M9 freeze; if for any reason that takes more than a couple of days from now, though, holler again.
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #286055 - Flags: approval126.96.36.199? → approval188.8.131.52+
Since we're using an approval queue on the trunk and Camino would like this patch to be able to land soon, I'm added checkin-needed to this bug. I've also talked to Reed and added it to his list of non-blockers to checkin. The instructions I'm giving are to checkin just the mozilla/config/config.mk change in attachment 286055 [details] [diff] [review]. Since that change can go in without the rest of the patch and gets the core part of this out of the way, it should be safe. This will probably land sometime over the weekend. http://wiki.mozilla.org/Firefox3/Beta2CheckinQueue#Non-Blockers Again: The checkin-needed keyword only applies to the mozilla/config/config.mk change in attachment 286055 [details] [diff] [review]. A Camino dev with check in the rest.
Checking in config/config.mk; /cvsroot/mozilla/config/config.mk,v <-- config.mk new revision: 3.377; previous revision: 3.376 done ss confused me, and I typoed the patch author/reviewer. Filed bug 403165 to fix it.
Landing on branch is blocked on bug 403273, but here's a combined code patch that applies against branch for when it's landable (and for sanity testing on 10.3.9 in the meantime; my test manifest mentioned above is still available). If anyone wants to land bug 403273 and this (or just this on trunk) before I get back next week, you have my blessing to do so.
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle will have to wait for next time
It seems it takes a really long time to fix something like this. Can't it just be added?
As it says in the whiteboard, read comment 27 before commenting here. Furthermore, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting further.
One thought that just occurred to me: do we want to bounce the update check through a mozilla.org URL with a redirect, to protect against any potential issues that could arise down the road with the cb.o domain/site?
Yeah, we probably do; all our in-client URLs work like that.
I'm not sure we can do https redirects through mozilla.org, but even if we can, I'm leaning toward making everything go directly to caminobrowser.org. We're now at a stable host that is providing us a free and consistent service (as they do for adiumx.com). I don't think we'll be plagued with the downtimes we've had in the past.
Comment on attachment 286055 [details] [diff] [review] Build patch for Sparkle approved for 184.108.40.206, a=dveditz
Attachment #286055 - Flags: approval220.127.116.11? → approval18.104.22.168+
I'm not going to have as much internet access this weekend as I had hoped; if anyone else has time and wants to check this in (or at least the config part for branch, so we don't miss another branch approval window) please do.
(In reply to comment #70) > I'm not going to have as much internet access this weekend as I had hoped; if > anyone else has time and wants to check this in (or at least the config part > for branch, so we don't miss another branch approval window) please do. > Done... Checking in mozilla/config/config.mk; /cvsroot/mozilla/config/config.mk,v <-- config.mk new revision: 3.337.2.12; previous revision: 3.337.2.11
Landed on MOZILLA_1_8_BRANCH. Yay! Leaving open for trunk landing.
Landed on trunk! Please file any specific issues as follow-up bugs.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [READ comment 27 BEFORE commenting]
You need to log in before you can comment on or make changes to this bug.