Release a new version? #1052
Comments
|
Bump @pointlessone |
|
I hear you. As soon as I get some time. |
|
We all use prawn when we generate .pdf files in ruby! \o/ |
|
I hope you have time soon to release a new gem version! 👍 |
|
Pretty please? 🤗 |
|
@pointlessone bump |
|
@Zyphrax Sure. Eventually. Some exciting work’s being landed on supporting gems. Once that’s done expect a new release. |
|
@pointlessone New PDF core commit and a few other good changes. Can we please have a new release? |
|
@Zyphrax Is there anything specific you need that is on master? Is there anything preventing you from using master? |
|
@pointlessone See my first post. The release version (2.2.0) causes warnings when your Rails bundle folder is a symlink, which is quite a common scenario for production environments. At the moment my Gemfile points to the specific commit that fixes the warnings, but it slows down bundle updates a lot. I see a lot of useful changes in the list of commits. |
|
@Zyphrax. No, not really. A new release will be issued once the work on TTFunk concludes. |
|
Looking forward to using pdf-core 0.8. Thanks for all your work on prawn. ❤️ |
|
@pointlessone Can you please do a bug fix/point release before you do this bigger release? Getting the dependencies synced up properly and any other bug fixes would be nice before something major comes down the pipe. |
|
@pointlessone You would make so many people happy with a small release. It has been almost 18 months now since the last version (Prawn 2.2.0) was released. Like @zenspider said, it would be great to have a small release before any big changes are introduced. There is almost no activity in the TTFunk repo. |
|
Would also love a patch release including #1065 |
|
Any updates concerning the next release? |
Hi there! Any news? |
|
@pointlessone bump bump bump |
|
@pointlessone Can we please get a release? I'm going to look at making a fork and publish it to RubyGems. |
|
I agree, please release a minor version update! |
Did this happen? At this point I would consider using a fork. |
|
I take a hint you all might be a bit frustrated. Let me give you a wee insight on the current state of affairs in hope it may help a bit. There won't be a release until a major feature land in TTFunk and the latest Rubocop will be happy with the state of prawn, pdf-core, and ttfunk repos. You can not help with TTFunk but can help with Rubocop. If you really want the release to happen sooner please submit PRs. If not, master branch seem to be sufficiently stable. We don't guarantee ever-stable master but we also try not to break it without necessity. Use BundlerEvery Ruby app in production I know of uses bundler. If yours doesn't you probably should look into it. It's really good. On top of that RubyGems support Gemfiles as well, to a certain extent (see To use Prawn master in your project put the following in your Gemfile: gem 'prawn', github: 'prawnpdf/prawn'If you don't want to get the latest code on every bundle update, you can give it a specific commit like this: gem 'prawn', github: 'prawnpdf/prawn', ref: 'fdf0445'Read more about git dependencies in Bundler docs. Please let me know how this doesn't solve your issue but a new release would. Forking guideIf this doesn't solve your issue and you still want to fork the project I can not stop you. After all this is how Open Source is meant to work. While I'm not a Copyright expert, I want to share a few findings in hope to make the process it smoother. Prawn name and logo belong to this project. You can not use those. You'll have to come up with a new name and logo (or at least remove the PRawn one). You'll have to remove Prawn name from anywhere in the project. However, you'll have to keep both the name and logo in git history. The code in its current form belongs to corresponding contributors. You can not remove attribution. So you'll have to keep git history because that's how attribution is preserved in this project. You can not do anything with the code (except for removing it, or modifying with another contribution) without the author's consent. That includes, changing license. So you'll have to either stick with current license or ask every contributor if they're OK with the change. This also makes fork integration a bit complicated. Presumably, you are forking the project to continue it's development. This means that your fork will eventually start deviating from Prawn codebase. You can take Prawn PRs to apply to your fork but you have to use unmodified patch (as it's an original work of the author) or ask author to contribute to your project similar patch if it can not be applied as is. Alternatively, you can ask permission to use their patch as a base if you want to modify it yourself to make it compatible with your fork. You'll still have to properly attribute the new modified patch. These are only a few things that spring to mind. But if your determination isn't wavered contact me after you properly set up your fork and I'll guide you through the release process as it's not as straight forward as one might wish. |
Why is this so mandatory? I don't understand why a linter can block a release :/ |
|
Mostly to remove security warning on the repo. Also it's not too much work and can be done while the feature is being developed. |
Yes. Done :) (see: #1102) If the feature you're developing is a new one maybe you could release it in a future version? |
|
@n-rodriguez I wonder why bundler method is not an option for you? |
Actually it's not only me but a lot of people who think like this. |
|
I understand that is a good heuristic when you’re picking up a random gem and not paying attention to it’s contents. But I don’t see a real argument in this particular case. How do you think a release would be different to current master? |
So "it's generally considered as a bad practice" is not an argument.... We're all gonna stick to master to please you 👍 |
|
“Generally considered as a bad practice” is not an argument. Someone some time decided that is the case. So it’s more an appeal to authority. You didn’t check their reasoning, did you? You can not tell if it is still the case. Both in general and in this specific case. Circumstances change and once in a while we should check if our heuristics are still good. Also you don’t need to do anything to please me. It makes very little difference to me personally if you’re using a cut gem or master. One thing I would ask though, please don’t push me to write one of those mainatainer rants abou who owns what to whom in OSS. There are plenty of those already. |
The "Someone" is the developer community (all languages included).
No. it's years of professional experience and also some discipline
I did. See above.
Did you? Some people are on the master branch for almost 2 years. It might be the right time for a small maintenance release ;) |
|
To avoid this kind of issues : #1096 |
|
@n-rodriguez You're referring to whole body of works of one specific famous person. That is as close as one can get to a definition of "appeal to authority" without actually opening a dictionary. You quote me very precisely. Let me be pretentious for a brief moment and quote myself.
To be more precise, please do so in your own words, without linking or quoting any external resource. And include specifics of your actual situation. Not a general tendency in the industry, not a hypothetical case, but your specific situation. I'll be glad hearing about those. Otherwise, thank you for engaging discussion and let's enjoy the rest of our weekends. Regarding #1096, a new release won't quite fix that issue. If anything, there's a chance it'll make it even worse. But thank you for reminding me. Once I have time I'll get to it. Eventually. |
I don't want to manualy check the diff of |
|
Beside the reasons why people don't want to use a specific git reference in their Gemfiles (which makes it harder to update, if you rely on semantic versioning in general for updating), could you maybe explain why you don't want to make a minor bugfix release for prawn @pointlessone ? What's the downside of a small bugfix release? And please guys: be kind to each other ❤️ |
|
We ask (the prawn users community) a simple solution : a new tag and a new release, and you answer with a tutorial about how to fork. Actually I don't understand... |
That is a valid concern. You should stick to the latest gem. But if there's a bugfix in master you really want, you can use
The request is simple. The delivery is not so much. I can not deliver soon. @h0jeZvgoxFepBQ2C (awesome username, BTW) Release process for Prawn is complicated and time consuming. At the moment I simply don't have enough time to actually do it. I'm not opposed to idea of a minor release. I'd loved if it every commit magically was a release. But unfortunately it's not. You all, dear Prawn community, probably have a vague idea that this project is remarkably non-commercial. Even though it's used by more than a few actual businesses and contributes to their success, none of them support Prawn*. So it's basically a hobby project for me. Which means that there are other thing before it in my priority list. It warms my heart knowing that you care so much about the project. It also breaks my heart knowing that I'm letting you down. But we all have to face the reality one way or another. It's a great shame that our expectations can not always be fulfilled. * Prawn used to be sponsored. A big chunk of Prawn was developed by a developer who worked basically full time on it. |
|
Hm.. But could you tell us why releasing a new version is so complicated? |
|
The simple version is Prawn is (at least) three gems that should've been one. Releasing just one often breaks others. So all three need to be released at the same time. As many have pointed out, a release is a big deal when it comes to stability, so that has to be tested as well. |
Maybe we could provide some help here ;)
A OSS developer be sure I do understand and respect that. But prawn is the de-facto library for manipulating PDF in ruby (at least the first result in Google) and as you said a lot of business use it and needs some stability and a bit of a long term view of things. |
If a lot of businesses use it, they should be interested in having a well-maintained library. Business (often) can't have both: free/gratis and well-maintained. If you are using Prawn in a commercial project, ask you boss if they could sponsor @pointlessone or someone else to work on it. @pointlessone does a great job with Prawn, pdf-core and ttfunk , given the time constraints and the complexity involved. |
|
First off, I want to say that I'm very disappointed in the direction this thread took... Possibly to the point that I would much rather use a fork at this point. The amount of defensiveness and language lawyering today is simply hostile and turns off people from wanting to contribute or even use said software. Second:
I might be misinterpreting your point, but I believe both of these assertions (logo/name must be removed and cannot modify code without permission) to be patently false. I do not believe that prawn has any registered trademarks protecting the name/ branding so if I wanted to release a fork under |
|
@zenspider I reread my comment and you're right on both accounts. I was mistaken on one account and didn't express my idea nearly clearly in another. I'm sorry for that. The amount of defensiveness is the result of the fork turn this discussion took. It pains me greatly that people consider forking before contributing. It feels like they want all the good stuff but try to actively leave me out of it. I'm sure no one actually thinks that but they act as if they do. From my perspective it's even more real because there was multiple calls for help. At one point there was an open call for maintainers. I got exactly zero replies for either. Yet people come with requests like this issue and get a bit disappointed when their (I believe unjustified) expectations are not met. "A nice project you've got there. It'd be a shame if someone forked it". You, Ryan, probably know better than anyone in community how easy it is to not meet someones expectations. Even with your admirable level of productivity. As I mentioned multiple times now, this project is a hobby. I have a limited use for it and I maintain it at that level. A couple years ago when previous maintainers were stepping down I picked this project up because I relied on it in a few projects. I didn't ask for regular releases or any specific features. I picked it up and made it work for me. I still make it work for me. But given that it actively competes with other aspects of my live it gets accordingly to the returns. I'm happy to spend some time reviewing PR when I get them, I meet new awesome people, I learn something new. My ego gets a little boost that I'm a part of something bigger. But this project doesn't contribute to my health, or bank account, doesn't have any positive effect on family. This weekend instead of chilling with a book I have to justify myself. Explain to strangers on the internet why they can not get some work from me. Their request being a thinly veiled threat instead of a polite question doesn't add much joy. Anyway, writing the forking guide, I admit, I was spiteful but still genuinely tried to be helpful. If someone believes they must do it I can't stop them. I was wrong about legal aspects but I believe it's a right thing to change name and logo when one does a proper fork. Releasing a namespaced built gem is not a fork. No one ever argues that a binary Linux kernel is a fork of the Linux Kernel project even with big patches applied. You don't even need to tell me if you do push Everyone, I'm sorry. This is most definitely not a good way to spend a weekend. I want to thank all the contributors to the project. Be it a PR, an issue report or answer, an email on the mailing list, or just a tweet. I really appreciate it. I'm sure everyone in the community does. I want to thank all the users. I'm glad you've found Prawn useful. I hope it will continue to be more help than detriment. Everyone who's no happy with the project, the way it's managed and me personally, I invite you to write me. My email is in my GH profile. I'll do my best to answer your questions and address your concerns. I ask for private communication to separate similar but different discussions. I believe, this can spare us all a bit of confusion. If you wish I can publish a summary afterwards. In any case, please consider a person on the other end. Try to be a bit kinder to them. I'm sorry I was not. Please don't be like me. |
I've been requesting a small patch release because:
That is unfortunately often the case with open source projects. I hope that helping others and maintaining the no 1 PDF library for Ruby gives you some satisfaction. If not, please don't take time away from spending time with your family. In my opinion family is always priority 1.
I opened this issue over a year ago. The last release is almost 2 years old. My goal was to get a release out there with the patch. It began with - a release is coming when I have the time - to - no sorry, can't release because we are waiting on changes to other libraries - to - why do you need a patch anyways, just point to the commit in bundler. My expectations were a bit off and I didn't realize it would be this time consuming to create a patch release, but I understand the complexity involved because of the dependencies. I can't help but feel that contributions feel a bit in vain though when there is so much time in between the commit and a release.
Don't be too hard on yourself. I think I speak for all of us in that we appreciate the work you do on this project! I'll close the issue. |
Are you still looking for other maintainers? That'd be a nice outcome here instead of a fork. You could , for example, train someone how to do releases, and then you could focus on PRs. |
I actually do. Call for maintainers is ever open. However, please don't expect to get full access the first time you ask. At the very minimum the candidate has to have a couple PRs merged just to get used to code style and process and get at least passing knowledge of the codebase. Recently we've got a new part-time maintainer for TTFunk. |
Great. That's all perfectly reasonable. I hope someone steps up to help. I think, if you could give some reassurance that that person's contributions would be eventually be released, you'd attract more interest. That's just my opinion, it's your project and if you're not willing to make that reassurance, that is entirely your decision. |
|
Of course, all contributions will be released eventually. I'm sorry I gave you impression there won't be a release ever. There definitely will be one (at least one). Just not today. |
|
I guess also not this year? A pity as 2.2.2 is broken. #1064 should have been merged a long time ago imho. |
|
I'm preparing for a gem release. Please see details in another issue. |
Could you please release a new version?
The current version was released on March 11th 2017.
The
Remove superfluous pdf-core requirescommit is really useful, silencing a few frustrating warnings. My Gemfile now points to that specific commit, but it is really slow when doing bundle updates.The text was updated successfully, but these errors were encountered: