-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
versioning #66
Comments
I at least would like to have the 1.1.8 with #67 because for me to upgrade to dev-master right now it would need serious testing. If doesn't happen I wiil have to fork it. |
there is now a 1.1.8 branch |
I'm wondering why we have this branches? Because it's harder to maintain and users can just stick to a specific commit, right? We should just dev in master and then release a beta for 1.2? I'm hoping that we can move @chrisboulton to tag a new release for PHP-Resque (chrisboulton/php-resque#112) |
Please consider using something like SemVer
It's only slightly more work and it makes the lives of your users considerably easier. Instead of getting minor patches and bug fixes automatically, users must regularly check to see if there are any updates that they might need (bugfixes, etc). If I depend on 20 packages, am I supposed to check them each every day for patches? You are doing your users a huge disservice. Further, any sensible developer who is going to use something in a production environment will install a package at the latest version (obviously not master, since master for 99% of other projects means 'unstable'). In the case of BCCResqueBundle, doing so will land you with a release that is two years old. |
PHP-Resque itself hasn't moved much in that same period. You're getting two year old code either way. Also, recommending SemVer in an issue whose opening post points out the same things SemVer does leads me to believe that there may be an incomplete understanding of the conversation. Just because it wasn't mentioned by name doesn't mean it's not already in place. |
Enough has changed that when I modified my composer.json to properly version lock this package everything broke and it took me a good few minutes of wasted time to figure out why. Perhaps I should have created a new issue. I really just wanted to bring up the conversation on versioning again and this issue seemed like a good place to do that. I don't understand the logic behind not using a versioning system. |
what do we do about versioning ?
as pointed out by @lightglitch in issue #63 we already have rather large changes in the master branch compared to 1.1.7
among these are:
so i guess my question is, do we create a separate branch based on 1.1.7 for issues we want to have in 1.1.8 - or do we discontinue the 1.1 brach and go for a new 1.2.0 release with the changes we have in master now.
any comments or thoughts on this ?
The text was updated successfully, but these errors were encountered: