Skip to content
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

Open
mrbase opened this issue Nov 25, 2013 · 6 comments
Open

versioning #66

mrbase opened this issue Nov 25, 2013 · 6 comments
Labels

Comments

@mrbase
Copy link
Contributor

mrbase commented Nov 25, 2013

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 ?

@lightglitch
Copy link
Contributor

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.

@mrbase
Copy link
Contributor Author

mrbase commented Nov 27, 2013

there is now a 1.1.8 branch

@ruudk
Copy link
Collaborator

ruudk commented Dec 10, 2013

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)

@wridgers
Copy link

Please consider using something like SemVer

Because it's harder to maintain and users can just stick to a specific commit, right?

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.

@danhunsaker
Copy link

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.

@wridgers
Copy link

PHP-Resque itself hasn't moved much in that same period. You're getting two year old code either way.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants