Hi all Thanks for the many reactions, and many ways to test package before using them in production. I think I'm going to try the extra wpkg-dir approach described below for now. As I am already doing something alike for our remote VPN/Home users who don't want software upgrades pulled trough the already too slow VPN. Those clients are now manually upgraded by running WPKG from a a whole separate WPKG dir + software dir burnt to a DVD+RW they can take home.. The only downside I see in this approach is that, as I said before, we have 4 to 5 test users. meaning that the 5th user is not always a test-user and sometimes doesn't want to be bothered with possible unstable software or experimental features..(sometimes the 4th user neither) Meaning that he sometimes wants to test package X (less possible production-severe impact) but not package Y (more dangerous package), and that won't be possible anymore with this approach.. Best regards Robin wpkg-users-bounces at lists.wpkg.org wrote on 21.02.2009 11:40:33: > [image removed] > > Re: [wpkg-users] Trying out package upgrades before general roll-outof package > > Rainer Meier > > to: > > Marco Gaiarin > > 21.02.2009 11:41 > > Sent by: > > wpkg-users-bounces at lists.wpkg.org > > Cc: > > wpkg-users > > Hi Marco > > I actually prefer another (much less "hackish" solution). I just > configure my test-systems to use another WPKG installation (might be on > the same share). Then you can simply upgrade the package on the > "testbed" installation of WPKG and simply copy over the package > definition as soon as you know it works. You can even use the same > software directories/paths if you use the version number within the > directory name. > > For example > %SOFTWARE% pointing to \\server\software\ > > Then put two versions of a program into this directory: > \\server\software\Pidgin v.2.5.3 > \\server\software\Pidgin v.2.5.4 > > Now install two WPKG versions: > > \\server\wpkg\wpkg.js > \\server\wpkg\packages\pidgin.xml <-- points to Pidgin v.2.5.3 > \\server\wpkg\... > > \\server\wpkg-testbed\wpkg.js > \\server\wpkg\packages\pidgin.xml <-- upgrade test for Pidgin v.2.5.4 > \\server\wpkg<... > > > This way you can simply test the package on your testbed machines > (configured to use 'wpkg-testbed'). When you finished testing just copy > pidgin.xml over to \\server\wpkg\packages\ and it will become productive. > > This way also allows you to test new versions of wpkg.js and other > modifications without affecting productive users. > > Sometimes it's not necessary to introduce too much complexity into a > program (wpkg.js) when there is a simple solution provided by the > operating system already. > > > By the way. I am thinking/workging on an extension of WPKG where it > would be possible to have multiple versions of a package defined in the > package database and then WPKG either selects the latest one or lets you > specify a specific one within the profile. However I am personally not a > friend of this solution because the solution outlined above gives you > more flexibility like full wpkg.js separation as well as diffetent > configuration (e.g you might want to use different config.xml / log > levels on testbed) without even a need to introduce any complex code > into wpkg.js which potentially creates problems. Every feature > implemented needs to be supported and fully tested for each following > release. As more complexity is added as more difficult it gets to > implement new things or even fix bugs in existing code. > > So give the solution outlined above a try. > > br, > Rainer -- Denk aan het milieu - is het nodig deze mail te printen? ** Email Disclaimer: ** This e-mail and the information it contains may be confidential, legally privileged and protected by law. Access by the intended recipient only is authorised. If you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. Any review, distribution, reproduction, publication or other use of this e-mail by persons or entities other than the intended recipient is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20090223/796a5708/attachment.html> |