Tag some versions

[bmidget]

The last version you tagged for this repo was Oct 13, 2012.

Please regularly tag some sort of release for your repo so those of us who install using composer don't have to use dev-master. It's not good practice for anyone to need to do that.

[danhunsaker]

Please search through existing issues before creating duplicates in a condescending tone.

If this project was progressing more regularly, releases would be tagged. However, several 1.3 features are still incomplete, but enough has changed that a 1.2.x release no longer makes sense under semantic versioning. So even though there have been commits to master in the interim, tagging any of them would be irresponsible at best.

All this is detailed in other issues about tagging releases.

[bmidget]

I understand what you're saying, but at the same time, there are tons of changes between 1.2 and master. Sure they don't constitute a 1.3 version. Maybe 1.2.5? Surely there is something changes could be tagged as so devs wouldn't have to use dev-master as our composer version. It's just asking for trouble from my standpoint when something is committed to master that breaks my entire application.

[danhunsaker]

This is the risk of using a project which is not currently being actively maintained.

[bmidget]

This has got to be the dumbest thing I've heard in my life. Three years' worth of changes. Small, but significant enough that it currently works and the last tagged version doesn't.

I'm sure every single user of this repo would agree with me that if someone took all of five minutes and tagged even a minor release (hey, why not 1.2.1), then we'll be happy knowing our locked in version won't break one day on our application.

[chrisboulton]

Hi Ben,

I absolutely agree with you.

The reality is that right now, I don't have the time to sit down and make the last set of changes I believe are necessary to cut a release that I am happy to sign off on the stability of.

At Bigcommerce, we're using a revision-locked-almost-HEAD copy of php-resque at the moment, but we're using it with a custom Redis client that provides Sentinel compatibility and uses Predis as the underlying Redis library. I want to get the library change into master and in the next release, as Predis is a better library overall.

I do also want to fold php-resque-scheduler into the next release to ensure compatibility (right now there is a nasty compatibility issue which is documented over in that repository and possibly here too). php-resque-scheduler itself needs some tests.

If a tagged release is super important to you now, I hope that means you are volunteering to help me test a branch with the above proposed changes if I can put one together. Alternatively, you can do what other people have been doing and choose an appropriate gitref and lock to that.

Sent from my iPad

On Jul 16, 2015, at 8:38 AM, Ben Midget notifications@github.com wrote:

This has got to be the dumbest thing I've heard in my life. Three years' worth of changes. Small, but significant enough that it currently works and the last tagged version doesn't.

I'm sure every single user of this repo would agree with me that if someone took all of five minutes and tagged even a minor release (hey, why not 1.2.1), then we'll be happy knowing our locked in version won't break one day on our application.

— Reply to this email directly or view it on GitHub.

[warren5236]

@chrisboulton I would be willing to work on testing the next release . What do you need me to do?

[chrisboulton]

274 is the "new" all encompassing "this project is doomed" issue - I'm going to close this one out in favour of that.