Re: Frozen Bubble 2.2.1
On Thu, Aug 5, 2010 at 3:20 AM, Guillaume Cottenceau gcott...@gmail.com wrote: Kartik and friends rewrote SDL_perl (a Perl module with SDL bindings) using a different API. Then they ported my Perl-based game to using that new Perl module, and to be CPAN-friendly. My game previous versions were 2.0.0, 2.1.0, 2.2.0, so now I would like it to be versioned 2.2.1. But prior to that, I would like to release a beta version because I suspect a couple of corner cases to contain bugs. So we're looking for a way to version it 2.2.1-beta1 or something similar, in order for it to NOT be included in stable distributions or replace 2.2.0 for regular users. Then we'll release 2.2.1 in a couple of weeks when no more important bugs are known. Thanks for your patience :) Let me restate what I think the situation is: * Frozen Bubble is now (or will be) a CPAN distribution rather than a standalone program distributed independently * You would like the CPAN version to indicate a beta status so that OS packagers don't blindly replace it for users I don't know exactly what criteria OS packagers use for deciding what is or isn't beta, but presumably the tarball name is significant. They may or may not be Perl experts familiar with CPAN conventions. I would suggest the following: * To be consistent with your prior versioning (dotted-decimal), require a minimum version of Perl that understands v1.2.3 numbering. That means 5.6.0 at a minimum, 5.8.1 is better, 5.10.0 is best but you might not want to impose that requimrent on end-users. * For the *modules* inside the distribution, follow CPAN conventions and include an underscore in the version number within the modules if they are beta e.g. our $VERSION = v2.2_1 Your final release should bump the last number and use a decimal our $VERSION = v2.2.2 (For the sake of simplicity and compatibility with Perl 5.10.0, I suggest that you NOT use the version.pm module.) * For the *distribution* (i.e. the tarball) you have more choices. For Perl people it would be sufficient to have this: Frozen-Bubble-v2.2_1.tar.gz But for people unfamiliar with CPAN conventions, I suggest one of the following: a) Frozen-Bubble-beta-v2.2_1.tar.gz b) Frozen-Bubble-v2.2_1-TRIAL.tar.gz c) Frozen-Bubble-v2.2.1-TRIAL.tar.gz In (a), you put beta in the title of the distribution, but leave the underscore in the version number. This tells PAUSE (the CPAN indexer) not to index this distribution, which is what you want for a beta. You might confuse some parts of the ecosystem like CPAN Testers, which will think that Frozen-Bubble is a different distribution than Frozen-Bubble-beta, but that's a fairly small price to pay. The (b) and (c) forms are not very common and take advantage of a little-known feature of PAUSE. Appending -TRIAL to the version number is another way of telling PAUSE not to index the distribution. If you do that, you have the choice of (b) or (c) as the underscore is no longer significant in the tarball name. Hopefully, that is also enough to warn off packagers. * If you accept -TRIAL as the answer that gives you a tarball name that packagers will know not to distribute and are consistent in always using it for your betas, then you could even stop using an underscore in the $VERSION variable and just use a period. our $VERSION = v2.2.1; * Just as a reminder, you still always want to bump the version numbers of your modules as you go from beta to final. CPAN conventions don't really support the concept of 2.2.1-beta followed by 2.2.1 (final). Numbers are expected to be monotonically increasing. You might want to adopt your own convention of odd numbers being development/beta and even numbers being releases. That's probably far more complex that you ever imagined, but I hope it gives you some useful direction. As I said in my article, it's really too bad that version numbers aren't boring. Thank you for writing such a cool game in Perl! PS: is an XY problem bound to a specific gender? do you think giving the problem to an XX person would solve it faster? :) The XY problem refers to wanting to do X, thinking Y is the right approach and asking how to do Y, but X is vital context and people might have better solutions than just Y. c.f. http://www.perlmonks.org/index.pl?node_id=542341 -- David
Re: Frozen Bubble 2.2.1
Kartik Thakore On 2010-08-05, at 7:07 AM, David Golden xda...@gmail.com wrote: On Thu, Aug 5, 2010 at 3:20 AM, Guillaume Cottenceau gcott...@gmail.com wrote: Kartik and friends rewrote SDL_perl (a Perl module with SDL bindings) using a different API. Then they ported my Perl-based game to using that new Perl module, and to be CPAN-friendly. My game previous versions were 2.0.0, 2.1.0, 2.2.0, so now I would like it to be versioned 2.2.1. But prior to that, I would like to release a beta version because I suspect a couple of corner cases to contain bugs. So we're looking for a way to version it 2.2.1-beta1 or something similar, in order for it to NOT be included in stable distributions or replace 2.2.0 for regular users. Then we'll release 2.2.1 in a couple of weeks when no more important bugs are known. Thanks for your patience :) Let me restate what I think the situation is: * Frozen Bubble is now (or will be) a CPAN distribution rather than a standalone program distributed independently Yes. * You would like the CPAN version to indicate a beta status so that OS packagers don't blindly replace it for users No, only the one on the main site. CPAN already has a differing versions. 2.111 on CPAN is 2.1.1beta1 for gc's os releases. The problem we are having is we cant force a non numerical VERSION in M::B for the non CPAN release. Our code uses the VERSION to compile a fb-server with output saying what version it is. This is why we need it in VERSION. I don't know exactly what criteria OS packagers use for deciding what is or isn't beta, but presumably the tarball name is significant. They may or may not be Perl experts familiar with CPAN conventions. I would suggest the following: * To be consistent with your prior versioning (dotted-decimal), require a minimum version of Perl that understands v1.2.3 numbering. That means 5.6.0 at a minimum, 5.8.1 is better, 5.10.0 is best but you might not want to impose that requimrent on end-users. * For the *modules* inside the distribution, follow CPAN conventions and include an underscore in the version number within the modules if they are beta e.g. our $VERSION = v2.2_1 Your final release should bump the last number and use a decimal our $VERSION = v2.2.2 (For the sake of simplicity and compatibility with Perl 5.10.0, I suggest that you NOT use the version.pm module.) * For the *distribution* (i.e. the tarball) you have more choices. For Perl people it would be sufficient to have this: Frozen-Bubble-v2.2_1.tar.gz But for people unfamiliar with CPAN conventions, I suggest one of the following: a) Frozen-Bubble-beta-v2.2_1.tar.gz b) Frozen-Bubble-v2.2_1-TRIAL.tar.gz c) Frozen-Bubble-v2.2.1-TRIAL.tar.gz This makes sense too. In (a), you put beta in the title of the distribution, but leave the underscore in the version number. This tells PAUSE (the CPAN indexer) not to index this distribution, which is what you want for a beta. You might confuse some parts of the ecosystem like CPAN Testers, which will think that Frozen-Bubble is a different distribution than Frozen-Bubble-beta, but that's a fairly small price to pay. thia dist_name = in M::B correct? The (b) and (c) forms are not very common and take advantage of a little-known feature of PAUSE. Appending -TRIAL to the version number is another way of telling PAUSE not to index the distribution. If you do that, you have the choice of (b) or (c) as the underscore is no longer significant in the tarball name. Hopefully, that is also enough to warn off packagers. * If you accept -TRIAL as the answer that gives you a tarball name that packagers will know not to distribute and are consistent in always using it for your betas, then you could even stop using an underscore in the $VERSION variable and just use a period. our $VERSION = v2.2.1; * Just as a reminder, you still always want to bump the version numbers of your modules as you go from beta to final. CPAN conventions don't really support the concept of 2.2.1-beta followed by 2.2.1 (final). Numbers are expected to be monotonically increasing. You might want to adopt your own convention of odd numbers being development/beta and even numbers being releases. That's probably far more complex that you ever imagined, but I hope it gives you some useful direction. As I said in my article, it's really too bad that version numbers aren't boring. Thank you for writing such a cool game in Perl! PS: is an XY problem bound to a specific gender? do you think giving the problem to an XX person would solve it faster? :) The XY problem refers to wanting to do X, thinking Y is the right approach and asking how to do Y, but X is vital context and people might have better solutions than just Y. c.f. http://www.perlmonks.org/index.pl?node_id=542341 Thank you so much for lots of cool things in Perl :) -- David Kartik
Re: Frozen Bubble 2.2.1
On Thu, Aug 5, 2010 at 7:45 AM, Kartik Thakore thakore.kar...@gmail.com wrote: thia dist_name = in M::B correct? Yes. Though maybe I should just implement a feature to add '-TRIAL', since I'll need that anyway for CPAN Meta 2 support. (Dist::Zilla already supports -TRIAL). -- David
Re: -TRIAL dists (was: Frozen Bubble 2.2.1)
# from David Golden # on Thursday 05 August 2010 08:55: Though maybe I should just implement a feature to add '-TRIAL', since I'll need that anyway for CPAN Meta 2 support. (Dist::Zilla already supports -TRIAL). Does search.cpan.org understand -TRIAL now? Last I looked, it was properly handled (i.e. not indexed) by PAUSE, but would leak through in a few other places where it appears that an assumption was being made without checking the index. It also looked like '-TRIAL' was intended to be used as a pre-release without bumping any version numbers, so you could have -TRIAL1, -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding that right? --Eric -- It works better if you plug it in! --Sattinger's Law --- http://scratchcomputing.com ---
Re: -TRIAL dists (was: Frozen Bubble 2.2.1)
On Thu, Aug 5, 2010 at 2:46 PM, Eric Wilhelm enoba...@gmail.com wrote: Does search.cpan.org understand -TRIAL now? Last I looked, it was properly handled (i.e. not indexed) by PAUSE, but would leak through in a few other places where it appears that an assumption was being made without checking the index. CPAN::DistnameInfo added support for '-TRIAL' in 0.10 back in March of this year and I'm pretty sure that's what Graham is using for search.cpan.org. It's certainly possible that it's leaking through elsewhere. rjbs has been doing -TRIAL releases of Dist::Zilla and may have a better sense of where any remaining issues are. It also looked like '-TRIAL' was intended to be used as a pre-release without bumping any version numbers, so you could have -TRIAL1, -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding that right? I believe that was specific to perl distributions, not CPAN distributions, but it may work for those as well. -- David
Re: Frozen Bubble 2.2.1
On Thu, Aug 5, 2010 at 2:02 AM, David Golden xda...@gmail.com wrote: On Wed, Aug 4, 2010 at 4:42 PM, Kartik Thakore thakore.kar...@gmail.com wrote: How do we make this work? I get a error doing this. I think you need to be a lot more specific about this. I'm beginning to suspect an XY problem. Walk us through -- step by step -- what you're trying to accomplish, the steps you're taking, and the errors that you're seeing. Kartik and friends rewrote SDL_perl (a Perl module with SDL bindings) using a different API. Then they ported my Perl-based game to using that new Perl module, and to be CPAN-friendly. My game previous versions were 2.0.0, 2.1.0, 2.2.0, so now I would like it to be versioned 2.2.1. But prior to that, I would like to release a beta version because I suspect a couple of corner cases to contain bugs. So we're looking for a way to version it 2.2.1-beta1 or something similar, in order for it to NOT be included in stable distributions or replace 2.2.0 for regular users. Then we'll release 2.2.1 in a couple of weeks when no more important bugs are known. Thanks for your patience :) PS: is an XY problem bound to a specific gender? do you think giving the problem to an XX person would solve it faster? :) -- Guillaume Cottenceau - http://zarb.org/~gc/
Re: -TRIAL dists (was: Frozen Bubble 2.2.1)
So how can we force the VERSION for the non CPAN release? Kartik Thakore On 2010-08-05, at 3:24 PM, David Golden xda...@gmail.com wrote: On Thu, Aug 5, 2010 at 2:46 PM, Eric Wilhelm enoba...@gmail.com wrote: Does search.cpan.org understand -TRIAL now? Last I looked, it was properly handled (i.e. not indexed) by PAUSE, but would leak through in a few other places where it appears that an assumption was being made without checking the index. CPAN::DistnameInfo added support for '-TRIAL' in 0.10 back in March of this year and I'm pretty sure that's what Graham is using for search.cpan.org. It's certainly possible that it's leaking through elsewhere. rjbs has been doing -TRIAL releases of Dist::Zilla and may have a better sense of where any remaining issues are. It also looked like '-TRIAL' was intended to be used as a pre-release without bumping any version numbers, so you could have -TRIAL1, -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding that right? I believe that was specific to perl distributions, not CPAN distributions, but it may work for those as well. -- David
Re: Frozen Bubble 2.2.1
It appears that your use case -- you want to publish the beta version on CPAN without having the non-beta-testers get it too -- is not supported by xdg's essay. I see two possible approaches: 1: leapfrogging. Release the beta versions with version numbers that are less than the latest release version. This approach might require some planning, possibly including bumping the version number on the current stable to make space. The beta testers will have to jump through something of a hoop, depending on their tools and skill with them, so you'll have to support them in that. 2: release beta versions in an entirely separate name-space, so instead of having the beta after Awesome::Application 3.003 having confusing version number just call it Awesome::Application_betatest 3.004 and let them coexist. Some research may be required to figure out the best way to do that -- you don't want CPAN.pm pulling in the Betatest version of something unreleased because it includes something that it thinks is a proper upgrade, for instance. The additional end-user control over what code is participating in the testing, for a module, with less risk, could be good, too, for a module.
Re: Frozen Bubble 2.2.1
Kartik Thakore On 2010-08-05, at 5:11 PM, David Nicol davidni...@gmail.com wrote: It appears that your use case -- you want to publish the beta version on CPAN without having the non-beta-testers get it too -- is not supported by xdg's essay. I dont know where you are getting this from. Suppose I have a Module::Build module that I never ever want to put on CPAN. How do I force the our $VERSION to be non numeric. I see two possible approaches: 1: leapfrogging. Release the beta versions with version numbers that are less than the latest release version. This approach might require some planning, possibly including bumping the version number on the current stable to make space. The beta testers will have to jump through something of a hoop, depending on their tools and skill with them, so you'll have to support them in that. No. Nothing to do with CPAN. 'non-CPAN'. 2: release beta versions in an entirely separate name-space, so instead of having the beta after Awesome::Application 3.003 having confusing version number just call it Awesome::Application_betatest 3.004 and let them coexist. Some research may be required to figure out the best way to do that -- you don't want CPAN.pm pulling in the Betatest version of something unreleased because it includes something that it thinks is a proper upgrade, for instance. The additional end-user control over what code is participating in the testing, for a module, with less risk, could be good, too, for a module. 'non-CPAN' regards, Kartik
Re: Frozen Bubble 2.2.1
With David's (xdg) help we have come up with a simple solution (which should have been more obvious). http://github.com/kthakore/frozen-bubble/blob/e5fe8243e67ca552c02099db8f5a274c6171e1b1/lib/Games/FrozenBubble.pm Please give that a run. The 'display' version is RELEASE_VERSION. Regards, Kartik
Re: Frozen Bubble 2.2.1
Hello, Is it possible to have 2.2.1beta1 VERSION, for a perl module? Kartik Thakore On 2010-08-04, at 2:21 PM, Guillaume Cottenceau gcott...@gmail.com wrote: On Wed, Aug 4, 2010 at 7:08 PM, Kartik Thakore thakore.kar...@gmail.com wrote: I dont think you can have that version. What if you did '2.2.1_2' that means a development version. Sorry, I would really like to say yes, but I've done quite some packaging work for Mandriva, and honestly this doesn't look like dev version (it looks awkward actually), We can ask perl module devel mailing list for help? If that would help why not :) Kartik Thakore On 2010-08-04, at 12:40 PM, Guillaume Cottenceau gcott...@gmail.com wrote: I of course do. [...@meuh /tmp/fb/frozen-bubble] git diff lib/Games/FrozenBubble.pm diff --git a/lib/Games/FrozenBubble.pm b/lib/Games/FrozenBubble.pm index b494f36..4bd46e7 100644 --- a/lib/Games/FrozenBubble.pm +++ b/lib/Games/FrozenBubble.pm @@ -1,6 +1,6 @@ package Games::FrozenBubble; -our $VERSION = '2.2.1'; +our $VERSION = '2.2.1beta1'; 1; [...@meuh /tmp/fb/frozen-bubble] ./Build clean ; perl Build.PL ./Build sudo ./Build install Cleaning up build files [Alien::SDL] Testing header(s): iconv.h [Alien::SDL] Testing header(s): math.h [Alien::SDL] Testing header(s): SDL.h [Alien::SDL] Testing header(s): SDL_mixer.h Creating new 'MYMETA.yml' with configuration results Can't find dist packages without a MANIFEST file Run 'Build manifest' to generate one WARNING: Possible missing or corrupt 'MANIFEST' file. Nothing to enter for 'provides' field in metafile. Creating new 'Build' script for 'Games-FrozenBubble' version 'v2.2.1' On Wed, Aug 4, 2010 at 6:38 PM, Kartik Thakore thakore.kar...@gmail.com wrote: ReRun perl Build.PL Kartik Thakore On 2010-08-04, at 11:18 AM, Guillaume Cottenceau gcott...@gmail.com wrote: On Wed, Aug 4, 2010 at 1:58 PM, Kartik Thakore thakore.kar...@gmail.com wrote: No go ahead and change that. I made a new branch for CPAN. I'm not able to set the version in your new build system. When I do that change --- a/lib/Games/FrozenBubble.pm +++ b/lib/Games/FrozenBubble.pm @@ -1,6 +1,6 @@ package Games::FrozenBubble; -our $VERSION = '2.2.1'; +our $VERSION = '2.2.1beta1'; 1; the build script still says: Creating new 'Build' script for 'Games-FrozenBubble' version 'v2.2.1' additionally, the build breaks server/fb-server.c; e.g. it replaces the C string concatenation of VERSION (before your breakage of e6f581b438c163ce1d9edd932b07dc3caba24987) to the actual version On Wed, Aug 4, 2010 at 4:35 AM, Guillaume Cottenceau gcott...@gmail.com wrote: On Wed, Aug 4, 2010 at 10:19 AM, Guillaume Cottenceau gcott...@gmail.com wrote: On Tue, Aug 3, 2010 at 8:04 PM, Kartik Thakore thakore.kar...@gmail.com wrote: The code is ready for you in Github. it seems that this fixes the version issue but the other questions in actually, it doesn't fully: it fixes the 2.210 = 2.2.1 issue but it doesn't additionally mark the beta status in the version (e.g. for example 2.2.1beta1). any problem with that? -- Guillaume Cottenceau - http://zarb.org/~gc/ -- Guillaume Cottenceau - http://zarb.org/~gc/ -- Guillaume Cottenceau - http://zarb.org/~gc/ -- Guillaume Cottenceau - http://zarb.org/~gc/
Re: Frozen Bubble 2.2.1
On Wed, Aug 4, 2010 at 4:12 PM, Guillaume Cottenceau gcott...@gmail.com wrote: Hum. This is for an application (a game), not a module, and I want it to be clearly labelled as a beta release. So fine with There are no standard conventions for alphanumerics, and you just make life hard for the machines, which means no help for the humans. but I don't see the big problem for machines and I don't know how to say hey this is beta only with numbers; especially if 5.005_03 is equivalent to 5.5.30, I don't see how this could be considered to mark it beta/dev :/ Thanks for your help.. Let me try to clarify. For a given Perl module called Foo, the $Foo::VERSION variable defines the version number that the perl interpreter will use to check against a minimum required version: use Foo 1.02; You can't put alphanumerics in $Foo::VERSION and have things behave nicely. However, a distribution -- by which I mean a tarball containing Perl modules, can have any name/number you want.. By convention, it should follow the same rules as for Perl module numbers, but it doesn't have to. The big downside to alphanumerics is that various CPAN ecosystem tools may not know how to interpret it as a number. If you don't plan on releasing this to CPAN, then you don't have to worry about it. If you do, then you should be aware of the conventions. They evolved organically over time, if that helps explain why things are the way they are. -- David
Re: Frozen Bubble 2.2.1
CPAN recognizes _ in the version variable as indicating a development version. This is easy if you're only releasing regular floating point versions i.e. 2.2 becomes 2.2_01. Does this work? I'm not clear on the validity of _ with 2 decimal versions. our $VERSION = '2.2.1_01'; On Aug 4, 2010, at 3:21 PM, David Golden wrote: On Wed, Aug 4, 2010 at 4:12 PM, Guillaume Cottenceau gcott...@gmail.com wrote: Hum. This is for an application (a game), not a module, and I want it to be clearly labelled as a beta release. So fine with There are no standard conventions for alphanumerics, and you just make life hard for the machines, which means no help for the humans. but I don't see the big problem for machines and I don't know how to say hey this is beta only with numbers; especially if 5.005_03 is equivalent to 5.5.30, I don't see how this could be considered to mark it beta/dev :/ Thanks for your help.. Let me try to clarify. For a given Perl module called Foo, the $Foo::VERSION variable defines the version number that the perl interpreter will use to check against a minimum required version: use Foo 1.02; You can't put alphanumerics in $Foo::VERSION and have things behave nicely. However, a distribution -- by which I mean a tarball containing Perl modules, can have any name/number you want.. By convention, it should follow the same rules as for Perl module numbers, but it doesn't have to. The big downside to alphanumerics is that various CPAN ecosystem tools may not know how to interpret it as a number. If you don't plan on releasing this to CPAN, then you don't have to worry about it. If you do, then you should be aware of the conventions. They evolved organically over time, if that helps explain why things are the way they are. -- David Todd Rinaldo to...@cpanel.net
Re: Frozen Bubble 2.2.1
On Wed, Aug 4, 2010 at 9:13 PM, David Golden xda...@gmail.com wrote: On Wed, Aug 4, 2010 at 2:59 PM, Kartik Thakore thakore.kar...@gmail.com wrote: Hello, Is it possible to have 2.2.1beta1 VERSION, for a perl module? It's not advisable. C.f. http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ Hum. This is for an application (a game), not a module, and I want it to be clearly labelled as a beta release. So fine with There are no standard conventions for alphanumerics, and you just make life hard for the machines, which means no help for the humans. but I don't see the big problem for machines and I don't know how to say hey this is beta only with numbers; especially if 5.005_03 is equivalent to 5.5.30, I don't see how this could be considered to mark it beta/dev :/ Thanks for your help.. -- Guillaume Cottenceau - http://zarb.org/~gc/
Re: Frozen Bubble 2.2.1
On Aug 4, 2010, at 3:12 PM, Guillaume Cottenceau wrote: On Wed, Aug 4, 2010 at 9:13 PM, David Golden xda...@gmail.com wrote: On Wed, Aug 4, 2010 at 2:59 PM, Kartik Thakore thakore.kar...@gmail.com wrote: Hello, Is it possible to have 2.2.1beta1 VERSION, for a perl module? It's not advisable. C.f. http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ Hum. This is for an application (a game), not a module, and I want it to be clearly labelled as a beta release. So fine with There are no standard conventions for alphanumerics, and you just make life hard for the machines, which means no help for the humans. but I don't see the big problem for machines and I don't know how to say hey this is beta only with numbers; especially if 5.005_03 is equivalent to 5.5.30, I don't see how this could be considered to mark it beta/dev :/ 5.005_03 is a string not a number.
Re: Frozen Bubble 2.2.1
On Wed, Aug 4, 2010 at 4:42 PM, Kartik Thakore thakore.kar...@gmail.com wrote: How do we make this work? I get a error doing this. I think you need to be a lot more specific about this. I'm beginning to suspect an XY problem. Walk us through -- step by step -- what you're trying to accomplish, the steps you're taking, and the errors that you're seeing. -- David
Re: Frozen Bubble 2.2.1
# from Guillaume Cottenceau # on Wednesday 04 August 2010 13:12: but I don't see the big problem for machines and I don't know how to say hey this is beta only with numbers; especially if 5.005_03 is equivalent to 5.5.30, I don't see how this could be considered to mark it beta/dev The first problem for machines is that $VERSION is a scalar and has no guaranteed structure to it, so you could put any string or whatever you want in it. Now when you try to compare that to something, you have to compare it as a number, so fun ensues because overloading involves objects and ... The second problem for machines is when you try to use packaging tools that expected a simple number in $VERSION or might try to complain about something that doesn't parse as a number. If you don't mind angering the machines, put whatever you want in there. But, why are humans seeing the raw value of $yourmodule-VERSION anyway? If it's an application, present / format it differently. You can still store whatever you want in it because it's mostly just a scalar. Might be a good idea to find some way to do it with a version.pm object just for maintainability. Now, for marking releases as Beta on the CPAN, well... --Eric -- The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. --George Bernard Shaw --- http://scratchcomputing.com ---
