Most likely, I will be releasing Neo/J 1.1 around June 22. If this is too late, don't worry as Neo/J 1.1 Release Candidate plus the latest patch will be the same the Neo/J official release.
Most likely, I will be releasing Neo/J 1.1 around June 22. If this is too late, don't worry as Neo/J 1.1 Release Candidate plus the latest patch will be the same the Neo/J official release.
Patrick
...except that the current 'latest patch' still says "NeoOffice/J 1.1 Release Candidate" in the title bar of every document, and still does periodic update checks.
Will the final official release disable update checking by default? Please?
Thanks, Patrick. I am aware of that but I think the point for discussion here is our request to have the reverse behaviour integrated into the official release so that we would have to opt in for automatic patch checking on an admin machine (say), rather than having to re-configure every new user installation to opt out.
I, for one, will certainly opt in and continue my support to this project but I don't need all my standard users downloading and attempting to install patches then calling me for 'support' when they can't authenticate the installation, for example.
Other options would be to pose the question during the installer or make the default period something like ever 3 months only, or even make the period user-configurable (including 'never' as the default option) during the install process? _________________ Ray Saunders
World Scout Bureau
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Wed Jun 08, 2005 9:06 am Post subject:
pluby wrote:
I will probably just have the Neo/J 1.1 final installer create the ".nocheckforpatches" file so that patch checking is disabled by default.
Patrick
Will there still be an option to "install"* patch checking though, via a custom installation (much like you can choose which additional components to install along with an OS install)?
I'm a bit undecided as to which should be the default behaviour - installing the block or not. Personally, I find the patch checking a little annoying, but that is because I am on the mailing list for the updates and I am a regular at the forums, so I don't need the prompting. However, will this be the case for most end-users? I think it might be better to have patch checking active by default, but allow people in Rays type of situation to custom install the blocker. You could also include this option in any subsequent patch installers so that once people are into the swing of looking for regular updates, or have subscribed to the mailing list, they can opt out of the checking.
* I realise it is actually un-installing the patch check blocker but it might not seem that way to an end user! _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
Will there still be an option to "install"* patch checking though, via a custom installation (much like you can choose which additional components to install along with an OS install)?
The Mac OS X installer tool does not have custom screens. Either I create the file or I don't. So, there is no user customization during the installation process.
The way the Mac OS X installation allows choice is through metapackages.
Patrick, how much work would it be to transform the Neo/J installer to be a metapackage which offers "NeoOffice/J" [non-optional] and "Disable Patch Update Checking" [optional], which would allow the user to opt-out and which would install only that one .nocheck file?
To me .mpkg sounds like it might be a lot of work to offer the option in a nice Mac OS X friendly way, but I'm not familiar with the Neo/J build process at all and not familiar enough with Package Maker (I do the libwpd packages manually through the GUI version because I only have to build and package every 6 mos or so).
As Neo/J is software , there will be bugs and fixes, even in a final release, so I'm undecided as to whether the patch-check should be on or off by default in a final release (definitely on in alpha/beta/release candidate). Ray makes a good argument about mass deployment.... Dunno. Even the .mpkg option might be annoying in mass deployment?
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Yes, a metapackage would work. However, we are extremely close to the official release date and, in my many years of software development, changing things at the last minute has burned me enough times that I will only consider making changings to fix critical (i.e. crashing) bugs. This is a preference issue so I am not making any changes to the installer.
So, let me repeat the options that I have offered:
1. Patch checking off by default
2. Patch checking on by default
Unless I hear overwhelming support to the contrary, I will turn off patch checking by default.
Would an additional "Check for updates" with a link to the patch page (identical solution to existing make donations) in the Help menu be a way out of this dilemma meeting both objectives?
No auto check by default but every user can check (and be encouraged to do so in the readme) whenever they have an urge.
Additionally, is it the intention to mail registered users with Patch release info or just .1+ updates?
Thoughts? _________________ Ray Saunders
World Scout Bureau
Would an additional "Check for updates" with a link to the patch page (identical solution to existing make donations) in the Help menu be a way out of this dilemma meeting both objectives?
Your suggestion involves more code changes than the metapackage idea so no, it is not an option at this point in time.
rays wrote:
Additionally, is it the intention to mail registered users with Patch release info or just .1+ updates?
I always announce both releases and patches to the NeoJUpdate mailing list. This will continue. I am opposed to sending out mail unless someone has "opted-in" as so many people are so sensitive about spam. Not surprisingly, many spammers use the argument that "we sending mail as a service to our customers" to justify their spam.
Your suggestion involves more code changes than the metapackage idea so no, it is not an option at this point in time.
I withdraw the suggestion. It was a shot in the dark... literally!
pluby wrote:
I always announce both releases and patches to the NeoJUpdate mailing list. This will continue. I am opposed to sending out mail unless someone has "opted-in" as so many people are so sensitive about spam.
Patrick
Me too. I take it from this that the registered users are auto-added to the NeoJUpdate list, in which case the readme just needs to reinforce the point that registration has real benefits and costs nothing.
It might mean making a minor distinction in the announcement messages between recommended updates (lower risk of bugs) and patches (higher risk of bugs) as a guide for the average end user? _________________ Ray Saunders
World Scout Bureau
Yes, a metapackage would work. However, we are extremely close to the official release date and, in my many years of software development, changing things at the last minute has burned me enough times that I will only consider making changings to fix critical (i.e. crashing) bugs.
Yeah, that too; if it's not difficult, it's dangerous Something for 1.5 Alpha, then
pluby wrote:
Unless I hear overwhelming support to the contrary, I will turn off patch checking by default.
I think it should be on, to keep users in contact with us and developments. That said, I'm not doing mass deployments, so if the mass deployment folks are all against it, I'm fine.
I also *think* it should be easy enough to write an AppleScript to toggle that, but I'll have to go read the instructions in the bug.
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
All times are GMT - 7 Hours Goto page Previous1, 2, 3Next
Page 2 of 3
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum