[Backgroundrb-devel] Restarting BackgrounDRb Means Restarting Mongrel?

Timothy Sanders tsanders at hiddenjester.com
Sun Jul 6 19:05:34 EDT 2008

Indeed. I wasn't trying to hurry you, I was just curious what the  
status was. Having said that, there's big perceived difference in  
stability between saying "We're using the 1.0.3 release" and "We're  
using the latest from git, which appears to be stable". I'm sure the  
current version *IS* stabler, but there's also a comfort level in  
having a tagged version, and it's just simply a matter of the  
processes and procedures in use on my project saying that we want a  
stable released version of all libraries in the production  
environment. If you were just a few days away from a major release  
then I'd agree that waiting for the list you wrote up is a good idea,  
but if you want more hands testing the current version of the master  
branch I'd suggest packing it up as a 1.0.4 updating it both in git  
and svn.

It seems a little like a chicken and the egg scenario where you want  
users to test out the new version, but some set of users won't be able  
to check it until there's a tagged version. While I can use any  
version I want in development, it's going to be a bigger deal for me  
to try to sell using the current version in production. And truthfully  
it's a little tricky for me to even go to a new version in development  
if I have no idea how long it will be before that version would be  
suitable for production.

It's possible that some of the issue here is simply that I'm not  
familiar with git - so maybe the master branch is equivalent to a  
tagged release. But if the "master branch" is basically the same thing  
as the "trunk revision" would be in svn or cvs, then if it's the  
version you want people using in production environments then I would  
encourage you to give it a new version number. If nothing else, simply  
so people can talk about what version the problem is against.  
Otherwise we're all in a sort of limbo where the master version can  
change at any moment and it's difficult to describe what version  
anybody is actually using.

My impression is that you feel if I was pushing a version to  
production today that I should use the git master, not 1.0.3, but  
that's not really a good solution for everyone. If the git master is a  
better version than 1.0.3, then it really deserves it's own version  
tag, and that's more important to me than whether said tag is 1.0.4,  
1.1, or 2.0.

On Jul 6, 2008, at 12:17 PM, hemant wrote:

> In past, I had some bad experience with hurried releases and don't
> want to repeat the same mistake, in the meanwhile, you can happily use
> git master, it works pretty rock solid and whenever required i roll
> out new fixes.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4619 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080706/9e3944c5/attachment.bin>

More information about the Backgroundrb-devel mailing list