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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please release a new version for Rails 4! #173

Closed
alto opened this issue Oct 8, 2014 · 11 comments
Closed

Please release a new version for Rails 4! #173

alto opened this issue Oct 8, 2014 · 11 comments

Comments

@alto
Copy link

@alto alto commented Oct 8, 2014

With all the patches included from the rails4 branch 馃槑

@radar
Copy link
Collaborator

@radar radar commented Oct 8, 2014

Only when Milestone 2.0.3 is complete.

@radar radar closed this Oct 8, 2014
@radar
Copy link
Collaborator

@radar radar commented Oct 8, 2014

Also:

gem 'paranoia', github: 'radar/paranoia', branch: 'rails4'

If you're that desperate.

@alto
Copy link
Author

@alto alto commented Oct 9, 2014

The last release is from January 2014. Does it really take more than 9 months (and counting) to release a patch version? Version 2.0.2 does not work well with Rails 4.1, so a patched version is urgently needed. It's not safe to use development branches (aka non-stable) in production.

@alto
Copy link
Author

@alto alto commented Oct 9, 2014

Another option would be to help you with Milestone 2.0.3 :)

@radar
Copy link
Collaborator

@radar radar commented Oct 9, 2014

It's quite annoying that you claim the branch is non-stable when all the tests are passing. If I were to do a release right now it would contain the same code as what's on that branch anyway.

So either you think that the branch is NOT STABLE and therefore unfit for release or you think it's fit for release and you refuse to use the branch.

Which is it?

On 9 Oct 2014, at 18:10, Thorsten B枚ttger notifications@github.com wrote:

The last release is from January 2014. Does it really take more than 9 months (and counting) to release a patch version? Version 2.0.2 does not work well with Rails 4.1, so a patched version is urgently needed. It's not safe to use development branches (aka non-stable) in production.


Reply to this email directly or view it on GitHub.

@radar
Copy link
Collaborator

@radar radar commented Oct 9, 2014

Also; by using a branch in a Gemfile you'll be locking down to a specific ref anyway, and so if I DID end up merging something that broke paranoia then you'd be safe because you would be locked to an older version.

On 9 Oct 2014, at 18:10, Thorsten B枚ttger notifications@github.com wrote:

The last release is from January 2014. Does it really take more than 9 months (and counting) to release a patch version? Version 2.0.2 does not work well with Rails 4.1, so a patched version is urgently needed. It's not safe to use development branches (aka non-stable) in production.


Reply to this email directly or view it on GitHub.

@radar
Copy link
Collaborator

@radar radar commented Oct 9, 2014

Helping with the 2.0.3 milestone is most welcome.

Complaining about when I, the owner of this repository, choose to do releases is not welcome.

On 9 Oct 2014, at 18:20, Thorsten B枚ttger notifications@github.com wrote:

Another option would be to help you with Milestone 2.0.3 :)


Reply to this email directly or view it on GitHub.

@alto
Copy link
Author

@alto alto commented Oct 9, 2014

I'm sorry if I trod on your foot. That wasn't my intention. I probably didn't choose my words right.

To clarify what I meant, with non-stable I simply meant a development branch, which might change at any given time and might break things (which can happen, and nobody's doing that on purpose). In fact, the rails4 branch is pretty mature in my point of view and ready for production (that's why I asked for a release in the first place).

Using, as you suggested, a :github/:branch ref, is feasible and safe, especially when the commit we are using works pretty well for us. We decide ourselves when to update to another commit (on that particular branch). You are totally right.

But having a release number at hand helps with communication (especially with issues in that regard). It states clearly (yes, one could argue that commit hashes do that as well) what you are using, and helps with identifying if others have problems with a particular release as well (instead of exchanging commit shas).

I didn't mean to complain about what you are doing or about your, the owner of this repository, decision not to do a release now. I asked in the first place, and tried to argue in the second. To call that "complaining" is your point of view, not mine. I'm just trying to convince you. But I agree, maybe my words didn't sound too nice, and I apologise for that. Expressing what you want to say, in the appropriate tone, is not always easy and straightforward for non-native speakers.

Sorry again, for treading on your foot. Feel free to decide when to do new releases. It's your repository.

@bluej100
Copy link
Contributor

@bluej100 bluej100 commented Nov 13, 2014

I feel like #104 is a pretty significant bug to have been in the latest release since January.

@radar
Copy link
Collaborator

@radar radar commented Nov 13, 2014

@bluej100 I said I would release a new version once the Version 2.0.3 milestone has been completed as the second post in this thread.

I do not have any time myself to work on this as I have a full-time job and in my spare time I am updating my Rails 4 in Action book.

If you would like to help out, you can do so by addressing the issues in that milestone.

Thanks.

@bluej100
Copy link
Contributor

@bluej100 bluej100 commented Nov 13, 2014

I have left comments on those three issues which I hope will be helpful.

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

Successfully merging a pull request may close this issue.

None yet
3 participants