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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
