<br><font size=2 face="sans-serif">Hi all</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the many reactions, and many
ways to test package before using them in production.</font>
<br><font size=2 face="sans-serif">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..</font>
<br>
<br><font size=2 face="sans-serif">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..</font>
<br>
<br><font size=2 face="sans-serif">Best regards</font>
<br><font size=2 face="sans-serif">Robin</font>
<br>
<br><tt><font size=2>wpkg-users-bounces@lists.wpkg.org wrote on 21.02.2009
11:40:33:<br>
<br>
> [image removed] </font></tt>
<br><tt><font size=2>> <br>
> Re: [wpkg-users] Trying out package upgrades before general roll-outof
package</font></tt>
<br><tt><font size=2>> <br>
> Rainer Meier </font></tt>
<br><tt><font size=2>> <br>
> to:</font></tt>
<br><tt><font size=2>> <br>
> Marco Gaiarin</font></tt>
<br><tt><font size=2>> <br>
> 21.02.2009 11:41</font></tt>
<br><tt><font size=2>> <br>
> Sent by:</font></tt>
<br><tt><font size=2>> <br>
> wpkg-users-bounces@lists.wpkg.org</font></tt>
<br><tt><font size=2>> <br>
> Cc:</font></tt>
<br><tt><font size=2>> <br>
> wpkg-users</font></tt>
<br><tt><font size=2>> <br>
> Hi Marco<br>
> <br>
> I actually prefer another (much less "hackish" solution).
I just<br>
> configure my test-systems to use another WPKG installation (might
be on<br>
> the same share). Then you can simply upgrade the package on the<br>
> "testbed" installation of WPKG and simply copy over the
package<br>
> definition as soon as you know it works. You can even use the same<br>
> software directories/paths if you use the version number within the<br>
> directory name.<br>
> <br>
> For example<br>
> %SOFTWARE% pointing to \\server\software\<br>
> <br>
> Then put two versions of a program into this directory:<br>
> \\server\software\Pidgin v.2.5.3<br>
> \\server\software\Pidgin v.2.5.4<br>
> <br>
> Now install two WPKG versions:<br>
> <br>
> \\server\wpkg\wpkg.js<br>
> \\server\wpkg\packages\pidgin.xml <-- points to Pidgin v.2.5.3<br>
> \\server\wpkg\...<br>
> <br>
> \\server\wpkg-testbed\wpkg.js<br>
> \\server\wpkg\packages\pidgin.xml <-- upgrade test for Pidgin v.2.5.4<br>
> \\server\wpkg<...<br>
> <br>
> <br>
> This way you can simply test the package on your testbed machines<br>
> (configured to use 'wpkg-testbed'). When you finished testing just
copy<br>
> pidgin.xml over to \\server\wpkg\packages\ and it will become productive.<br>
> <br>
> This way also allows you to test new versions of wpkg.js and other<br>
> modifications without affecting productive users.<br>
> <br>
> Sometimes it's not necessary to introduce too much complexity into
a<br>
> program (wpkg.js) when there is a simple solution provided by the<br>
> operating system already.<br>
> <br>
> <br>
> By the way. I am thinking/workging on an extension of WPKG where it<br>
> would be possible to have multiple versions of a package defined in
the<br>
> package database and then WPKG either selects the latest one or lets
you<br>
> specify a specific one within the profile. However I am personally
not a<br>
> friend of this solution because the solution outlined above gives
you<br>
> more flexibility like full wpkg.js separation as well as diffetent<br>
> configuration (e.g you might want to use different config.xml / log<br>
> levels on testbed) without even a need to introduce any complex code<br>
> into wpkg.js which potentially creates problems. Every feature<br>
> implemented needs to be supported and fully tested for each following<br>
> release. As more complexity is added as more difficult it gets to<br>
> implement new things or even fix bugs in existing code.<br>
> <br>
> So give the solution outlined above a try.<br>
> <br>
> br,<br>
> Rainer<br>
<br>
</font></tt>