What should you do when you tag a wrong commit and you would want to re-tag?
If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you're done.
But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:
1.
The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have *different* "X"'s. So just call it "X.1" and be done with it. 2.
The insane thing. You really want to call the new version "X" too, *even though* others have already seen the old one. So just use *git tag -f* again, as if you hadn't already published the old one.
====
So really, can we just stick with the sane thing? It seems to be working well for Git users and many before that, I don't think we'll be insulting anyone's intelligence. We're all human, you messed up: yank, push, done. At least now you can correct that mistake.
On Tue, Mar 2, 2010 at 2:59 PM, 7rans <transf...@gmail.com> wrote:
> On Mar 2, 11:17 am, Chad Woolley <thewoolley...@gmail.com> wrote: > > On Tue, Mar 2, 2010 at 6:57 AM, 7rans <transf...@gmail.com> wrote: > > > "bump the version" Huh? That exactly what I just said I did not want > > > to do.
> > Just because you don't want to do it doesn't mean it isn't the right > > thing to do.
> > From my perspective as a gem user, I don't want to trust you (or > > anyone, nothing personal) to not release the same version with > > breaking changes. If you did, this would mean my previously working > > deploy suddenly stopped working when I downloaded the same gem version > > on a new machine. That would be very bad.
> No. A developer wouldn't repush a gem to break it or even to change it > in an incompatible way. They would do so to FIX it. The problem with > what you are suggesting is the your are perpetuating the use of non- > functional code.
> This isn't about trusting a developer. You are implicitly not trusting > any developer by forcing them to bump a version and forcing them to > make any version no matter what be available for download.
> Consider a scenario where an overlooked bug caused the current > directory to be completely deleted or some really bad bug like that. > You think that gem should still be available for people to use just > because it was released like that? Hell no! Not only should that bug > be fixed, but that entire chance of getting that code again should be > eradicated. And if such a gem was released recently, a repush is a > quick fix to stem the tide --and of course in such a bad case as this, > one should inform potential users right away.
> > Weigh this against the cost of you bumping your version (which as John > > pointed out will be automated), and the choice is easy. Make everyone > > bump the version.
> > It seems that you are overly concerned about your 'broken' code > > existing in the wild. That doesn't really matter. EVERYBODY releases > > broken code. It's open source, you are doing a great thing by > > releasing the code at all! Congratulations! If you have a bug, even > > in your release metadata; that's what a version bump (and release > > notes) are intended to address.
> Clearly. But I am the developer and I want control over my projects. I > don't want others forcing me to do things certain ways if I decide > otherwise. That's always been part of the traditional Ruby mind -- > Ruby gives you the rope to hang yourself. That's they way I want it to > be. That's why I use Ruby. It's like the 2nd Amendment.
> > It isn't a problem or a reflection on > > you at all. Frequent releases are good.
> I have never believed that. If that were really true, we'd release a > new versions every time our tests all passed. Releasing when it is > time to release is good.
> > However, inadvertently breaking a feature with an innocuous 'fix', > > then rereleasing it over the previously-working version (thereby > > making the working version unavailable) IS a problem, and people > > should be prevented from doing it.
> You have it completely backwards. You think you know better then the > developer that his gem is "previously-working" and the developer is > dumb enough to repush a broken 'fix'? So you, in your wisdom, are > going to save the dumb developer from himself by forcing him to push > that gem, you know the one "inadvertently breaking a feature with an > innocuous 'fix'", with a bumped version. And that's going to fix the > problem?
On Mar 2, 11:37 am, Wincent Colaiuta <w...@wincent.com> wrote:
> Can you remind us which gems you maintain? Just so I can add them to my "steer clear" list.
> If you're the sort of developer that thinks it's ok for one person to download "version 1.0" of something and then the next to download something different > that _also_ claims to be "version 1.0", then your standards of rigorousness probably aren't what I'm looking for.
But that's the part of point I am trying to make. It's is a false sense of rigor. If a developer decides to repush it's b/c he has a reason, like making sure no else gets a broken package. If you can't trust him to make that decision, how is forcing him to bump the version going to help? The point is to help, not hurt. We're not talking about releasing gem, announcing it, and then coming back a week later and repushing b/c there's a new feature to go out. Versions have a pragmatic purpose. Dependency constraints generally use ">=" and "~~>", they don't see the difference between 1.0.0.0 and 1.0.0.1. Why? Because if the developer is doing his job there is no appreciable difference to the end user. 1.0.0 does equal 1.0.0 even though they are not exactly the same.
Understand, that I am not saying don't bump the version. I understand everything you all are saying. And yes, by all means bump the version, that's the formal procedure. All I am saying is don't tie a developer's hands completely should he decide he needs to do something outside the norm. For me, in almost every case it's something I've done within minutes of a previous release, when I discovered either a typo that slipped by my tests (eg. once it was "each" spelled "ecah") , or a typo in some documentation, and I just wanted to go ahead and get it in there without adding a release history entry for a small doc change.
If you want to protect inexperienced developers from a repush when they shouldn't then I would suggest that 1) only allow a repush when the version has zero downloads and 2) provide a --force-repush option for special cases.
> If you want to protect inexperienced developers from a repush when > they shouldn't then I would suggest that 1) only allow a repush when > the version has zero downloads and 2) provide a --force-repush option > for special cases..
... or just keep using the sane default of bumping versions.
On Tue, Mar 2, 2010 at 12:59 PM, 7rans <transf...@gmail.com> wrote: > Consider a scenario where an overlooked bug caused the current > directory to be completely deleted or some really bad bug like that. > You think that gem should still be available for people to use just > because it was released like that? Hell no! Not only should that bug > be fixed, but that entire chance of getting that code again should be > eradicated. And if such a gem was released recently, a repush is a > quick fix to stem the tide --and of course in such a bad case as this, > one should inform potential users right away.
Hi,
I'm trying hard to discuss and address all your concerns, so you don't just feel dismissed.
The particular case you mention above is the only one where I can kind of see your point - someone releases a gem version which is not just buggy, but actually dangerous (e.g. recursively deleting current dir). Let's discuss it:
* First of all, this is probably a very rare case, and even rarer for someone in this situation to think of addressing it by re-releasing as same version (unless they are you) :) * Secondly, the current 'yank' functionality would prevent anyone from getting the gem via normal RubyGems commands - they'd have to manually download it. * Finally, if you are still worried about somebody manually downloading it, you could contact GemCutter support (aka Nick), explain the situation, and ask him to purge it from S3. Given the rarity of this situation, this seems like an acceptable compromise - especially since the much-more-likely alternative is that naive developers will unknowingly abuse the feature in a 'non-sane' way (as has been thoroughly discussed in this thread - see the Git tag docs)
Sorry if you don't agree, but I think the current approach is by far what most people would prefer. That's the beauty of Open Source - when it works well, it is a Meritocracy, and the best ideas (as judged by the community) rise to the top. That is exactly what happened here, and it makes me happy.
On Mar 2, 9:53 pm, Chad Woolley <thewoolley...@gmail.com> wrote:
> On Tue, Mar 2, 2010 at 12:59 PM, 7rans <transf...@gmail.com> wrote: > > Consider a scenario where an overlooked bug caused the current > > directory to be completely deleted or some really bad bug like that. > > You think that gem should still be available for people to use just > > because it was released like that? Hell no! Not only should that bug > > be fixed, but that entire chance of getting that code again should be > > eradicated. And if such a gem was released recently, a repush is a > > quick fix to stem the tide --and of course in such a bad case as this, > > one should inform potential users right away.
> Hi,
> I'm trying hard to discuss and address all your concerns, so you don't > just feel dismissed.
Thanks Chad. My apologies if I conveyed that I would feel such a way. My only wish is to discuss it, and I am fully open to being wrong.
> The particular case you mention above is the only one where I can kind > of see your point - someone releases a gem version which is not just > buggy, but actually dangerous (e.g. recursively deleting current dir). > Let's discuss it:
> * First of all, this is probably a very rare case, and even rarer for > someone in this situation to think of addressing it by re-releasing as > same version (unless they are you) :)
:) Just to be clear I would only do that if I knew I'd be following it up with new version relatively soon. Otherwise I'd have it deleted. Actually this is were pre-releases would come in, but I haven't yet started to utilize this relatively new feature of Rubygems. Once I start to do that, this whole thread might well be moot. That brings up a good question actually: Will there be a way to delete pre-releases or do I have ask Nick to do that too?
But I digress... Honestly, I find it more odd that people are so casual about leaving knowingly broken wares available for download.
> * Secondly, the current 'yank' functionality would prevent anyone from > getting the gem via normal RubyGems commands - they'd have to manually > download it. > * Finally, if you are still worried about somebody manually > downloading it, you could contact GemCutter support (aka Nick), > explain the situation, and ask him to purge it from S3. Given the > rarity of this situation, this seems like an acceptable compromise - > especially since the much-more-likely alternative is that naive > developers will unknowingly abuse the feature in a 'non-sane' way (as > has been thoroughly discussed in this thread - see the Git tag docs)
That's fine. I mean I hate to bug Nick to get a gem deleted, it also means more time for me. I personally would rather not keep a gem up there if I know it is broken and the next version will do just as well. It's really just wasting space b/c honestly no one is going to use it.
So I'm not even sure yank is going to do much. Given what I have heard here. Why would you yank if you just bump and release. If the situation was such that you felt you needed to yank, then it is probably bad enough for you to contact Nick to delete it too. And also I wonder if you did use yank, how do you think that will reflect on you as a developer if your release list has a number of yanks in it? Since there is no reason given for the yankings, what will be surmised?
> Sorry if you don't agree, but I think the current approach is by far > what most people would prefer. That's the beauty of Open Source - > when it works well, it is a Meritocracy, and the best ideas (as judged > by the community) rise to the top. That is exactly what happened > here, and it makes me happy.
I don't disagree. I just hate to loose my flexibility as a developer, even git allows you to delete remote tags, even if that's almost certainly a bad idea. I am just arguing from a more pragmatic position. In many cases it's really not a significant issue, and the developer can be afforded some discretion.
Probably the biggest argument against my position, is when someone downloads a new version (maybe seconds after it's been pushed) then runs into a bug, but never realizes that a fix has been pushed later b/ c the version hasn't changed. Of course, in such a case they either will not use the gem anyway b/c it "appears buggy" or, if they really want to use it, will report the bug, maybe with a patch, upon which they would have to be informed that it's already been taken care of and they need to uninstall the latest version and reinstall -- a bit annoying and another potential time waster.
> Sorry if you don't agree, but I think the current approach is by far > what most people would prefer. That's the beauty of Open Source - > when it works well, it is a Meritocracy, and the best ideas (as judged > by the community) rise to the top. That is exactly what happened > here, and it makes me happy.
Oh yea! I just ran into this tyranny tonight.
Pushing gem to RubyGems.org... Repushing of gem versions is not allowed. Please use `gem yank` to remove bad gem releases.
You see I just pushed a gem a few minutes ago. And not 3 seconds after I pushed it I realized I forgot to make an entry in the HISTORY file for the release. So I add the entry, takes a whole 3 minutes. And then, well here I am. I can't make the quick fix. So now what? I'm supposed to yank it? Why? It still works. Should I contact Nick and ask him to delete it so I can repush? No, that's right I am supposed to bump the version. So now there will be two gem files up on the cloud completely the same except for a small entry in the HISTORY file. Oh yea, and now I need to add another entry to the HISTORY file for this new version, eg.
= Release History
== v0.6.0.1
* 1 Enhancement
* Updated this History File
Er... no. I won't be doing that. f* it. I'm just leaving the old HISTORY file. It's not worth the hassle. The project is in early development anyway (which makes this restriction even more ridiculous), and there will likely be a new release in the not too distant future. So for now too bad for any one reading the HISTORY file. They can blame meritocracy.
On Thu, Mar 4, 2010 at 4:12 PM, 7rans <transf...@gmail.com> wrote: >> Sorry if you don't agree, but I think the current approach is by far >> what most people would prefer. That's the beauty of Open Source - >> when it works well, it is a Meritocracy, and the best ideas (as judged >> by the community) rise to the top. That is exactly what happened >> here, and it makes me happy.
> Oh yea! I just ran into this tyranny tonight.
Mate, chill. So you forgot to update this history file, no big deal. If it was a big deal, you release another gem version, if it isn't let it sit till the next gem release.
On Wed, Mar 3, 2010 at 10:12 PM, 7rans <transf...@gmail.com> wrote: > You see I just pushed a gem a few minutes ago. And not 3 seconds after > I pushed it I realized I forgot to make an entry in the HISTORY file > for the release.
On Wed, Mar 3, 2010 at 11:12 PM, 7rans <transf...@gmail.com> wrote: >> Sorry if you don't agree, but I think the current approach is by far >> what most people would prefer. That's the beauty of Open Source - >> when it works well, it is a Meritocracy, and the best ideas (as judged >> by the community) rise to the top. That is exactly what happened >> here, and it makes me happy.
> Oh yea! I just ran into this tyranny tonight.
> Pushing gem to RubyGems.org... > Repushing of gem versions is not allowed. > Please use `gem yank` to remove bad gem releases.
> You see I just pushed a gem a few minutes ago. And not 3 seconds after > I pushed it I realized I forgot to make an entry in the HISTORY file > for the release. So I add the entry, takes a whole 3 minutes. And > then, well here I am. I can't make the quick fix. So now what? I'm > supposed to yank it? Why? It still works. Should I contact Nick and > ask him to delete it so I can repush? No, that's right I am supposed > to bump the version. So now there will be two gem files up on the > cloud completely the same except for a small entry in the HISTORY > file. Oh yea, and now I need to add another entry to the HISTORY file > for this new version, eg.
> = Release History
> == v0.6.0.1
> * 1 Enhancement
> * Updated this History File
> Er... no. I won't be doing that. f* it. I'm just leaving the old > HISTORY file. It's not worth the hassle. The project is in early > development anyway (which makes this restriction even more > ridiculous), and there will likely be a new release in the not too > distant future. So for now too bad for any one reading the HISTORY > file. They can blame meritocracy.
There's really no need for this sarcasm. Most of the people involved with this conversation have been extremely patient with you throughout this entire thread, and have gone out of their way to be respectful in spite of the fact that you've been simply unwilling to see the alternate view.
Versions mean something.
The problem that you continue to miss is that some projects have a lot of users who depend on version numbers being something reliable, and while _you_ may well have the chops to make an intelligent decision about when it's OK to blow away the old version 1.0.0 and replace it with a new one, not everyone does. I, personally, don't want to play in an environment when I can't trust that John's foo-1.0.3 and Jane's foo-1.0.3 and my foo-1.0.3 are the same gem, and I think that's the sentiment expressed by everybody else in this conversation.
In this case, you made a simple error, but it was _your_ error, and you're asking an entire community to accept a process that makes it easier for you to cover for your errors, while exposing it to a wealth of insecurity and potential instability. You have at least two solutions to fix the problem you created. Yank 1.0.0 and release 1.0.1, or yank 1.0.0, request that it be permanently deleted, and _then_ re-release it. The latter solution gets you where you want to get, but with a few extra steps (maybe you'll be more careful next time), and it doesn't impose your sense about what versions mean on the rest of us.
>> Sorry if you don't agree, but I think the current approach is by far >> what most people would prefer. That's the beauty of Open Source - >> when it works well, it is a Meritocracy, and the best ideas (as judged >> by the community) rise to the top. That is exactly what happened >> here, and it makes me happy.
> Oh yea! I just ran into this tyranny tonight.
What I first mistook for mere stupidity and ignorance is now looking like active trolling. Best not to continue feeding it.
On Tue, Mar 23, 2010 at 4:00 PM, rogerdpack <rogerpack2...@gmail.com> wrote:
> > Hey folks, thanks to some great work from John Trupiano we now have gem > yank > > live on the site.
> Sweet worked like a charm (well, after like 20 minutes, but it > worked). > Thanks. > -rp
> To unsubscribe from this group, send email to gemcutter+ > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > ME" as the subject.
It's interesting to me that this is such a heated debate, and reading straight through the whole thing I realize that there are two issues here that are combining to create 3 separate stances on the topic. So let me be a moderator here. The two issues are Good Practice and Responsibility.
Good Practice: Versioning. Please bump your version. Users of your code depend on you. Responsibility: Users depend on code consistency (versioning), so responsibility is important.
In the area of Good Practice, it looks like everyone agrees that versions have a purpose, that for any added functionality and bugfixes alike, the version should be bumped. The only difference I see at this point is that some would like to be able to overwrite a previous version (which may include ALSO adding a new version with the changes) in the following cases: 1) The current/previous version has a dangerous flaw. (Perhaps other libraries or programs depend on specifically this version and this dangerous flaw was not discovered until a few versions later.) 2) The developer has just pushed the code but realized something wasn't right for this deploy. There are sometimes a whole lot of things involved in a deploy, such as: making sure we're on the right git branch, remembering to update the changelog / history / readme / etc, including all files in the manifest (hey, some gems may not be on the newest jeweler code yet), possibly generating seed files necessary for a new gem version, and more. 3) Versions mean something. When the entire reason for a new version is nullified by a bug that is identified before any users have downloaded the new version, of course I'd rather re-push the same version, fixed, than bump the version up again and have a useless (and possibly yanked) version in my history. 4) Other cases may exist where outside constraints (whether in developer's control or not, whether good choices or not) cause re- pushing to be the only reasonable option, despite the warnings we all agree upon against not bumping a version.
In the area of Responsibility, we have a heated debate. Who is responsible for making the versioning make sense? The users of my gem trust me for my code, not gemcutter / rubygems.org. What kind of trust are they putting in rubygems.org? We all understand the problem of faulty versioning; the question is not "Do we address this problem?" but rather "How do we address this problem?" Some have already chosen to have rubygems.org police this policy and enforce this "Good Practice". The thing is, as 7rans said, "I am the developer and I want control over my projects." Let's look at git for a second, as Nick brought up: We all understand tagging pretty much the same way as versioning. It has the same issues and potential problems we have with versioning / re-versioning. But does git tie our hands and prevent us from doing "the wrong thing"? No. However, rubygems.org is a service, not just a tool in the shed, so they do feel some responsibility for this as well. But we have to concede a compromise. Sometimes re- pushing is the only good solution. Seldom, VERY seldom, but it is true.
The solution I would propose for this problem is: Make it possible, but make it very hard. This discourages doing this as a general practice, but allows developers to do it -- only if they really know what they're doing.
My personal policy on this would allow myself to re-push as long as there are zero downloads so far, and then allow me to force-re-push later for edge cases, such as when I need to fix a horribly dangerous bug in a previous version whose api other libraries may depend on. In this case I must really know what I'm doing because of course I don't want to change the api (that's the reason I need to fix this old version in the first place). If I need to fix a horribly dangerous bug in an older version, I would not be afraid to push a new version with the fix as well. I just may understand the need to fix the bug in a previous version as well, because I don't want dangerous code sitting there waiting for people to use it just because some other library depends on that specific version (for better or for worse, but a library that I can't control). To go along with this policy I would expect gemcutter to: 1) allow free re-pushing as long as the version has zero downloads 2) allow re-pushing after downloads only with a --force option, accompanied with the SHA for the re-push in order to confirm that I really know what I'm doing and that it's worth walking the extra mile to do the unconventional and almost-always not-recommended. Could also require an interactive confirmation "Are you sure? Y/[N]" with enough explanation of the issue and a HIGHLY-NOT-RECOMMENDED message.
Lastly, for gemcutter to enforce versioning is a strange mismatch of trust: it trusts the developer to know what they're doing in releasing code in the first place, but it doesn't trust the same developer when it comes to versioning that code. Developers are not expected to provide their users with the same level of trustworthiness that they already provide in the code itself. Again, just a mismatch of trust here between gemcutter and developer.
I agree with you all about the good practice of versioning, but I don't like having someone else police what is my responsibility of sensible versioning. I also don't like the complete inability to provide a fixed version of a deadly older version of a gem that is locked in as a dependency of other libraries -- if that were to ever happen.
Requiring the developer to explicitly provide the SHA of a re-push is IMO a pretty good way to be sure the developer knows what they're doing if they need to re-push. Also a pretty good way of discouraging the use of this functionality to the point that nobody would want to use it every day. You'd have a re-push rejected by default with a nice message that explains the issue and instructs the use of --force and -- sha=1234567890 to force a re-push.
- daniel parker -
On Mar 4, 1:41 am, David Chelimsky <dchelim...@gmail.com> wrote:
> On Wed, Mar 3, 2010 at 11:12 PM, 7rans <transf...@gmail.com> wrote: > >> Sorry if you don't agree, but I think the current approach is by far > >> what most people would prefer. That's the beauty of Open Source - > >> when it works well, it is a Meritocracy, and the best ideas (as judged > >> by the community) rise to the top. That is exactly what happened > >> here, and it makes me happy.
> > Oh yea! I just ran into this tyranny tonight.
> > Pushing gem to RubyGems.org... > > Repushing of gem versions is not allowed. > > Please use `gem yank` to remove bad gem releases.
> > You see I just pushed a gem a few minutes ago. And not 3 seconds after > > I pushed it I realized I forgot to make an entry in the HISTORY file > > for the release. So I add the entry, takes a whole 3 minutes. And > > then, well here I am. I can't make the quick fix. So now what? I'm > > supposed to yank it? Why? It still works. Should I contact Nick and > > ask him to delete it so I can repush? No, that's right I am supposed > > to bump the version. So now there will be two gem files up on the > > cloud completely the same except for a small entry in the HISTORY > > file. Oh yea, and now I need to add another entry to the HISTORY file > > for this new version, eg.
> > = Release History
> > == v0.6.0.1
> > * 1 Enhancement
> > * Updated this History File
> > Er... no. I won't be doing that. f* it. I'm just leaving the old > > HISTORY file. It's not worth the hassle. The project is in early > > development anyway (which makes this restriction even more > > ridiculous), and there will likely be a new release in the not too > > distant future. So for now too bad for any one reading the HISTORY > > file. They can blame meritocracy.
> There's really no need for this sarcasm. Most of the people involved > with this conversation have been extremely patient with you throughout > this entire thread, and have gone out of their way to be respectful in > spite of the fact that you've been simply unwilling to see the > alternate view.
> Versions mean something.
> The problem that you continue to miss is that some projects have a lot > of users who depend on version numbers being something reliable, and > while _you_ may well have the chops to make an intelligent decision > about when it's OK to blow away the old version 1.0.0 and replace it > with a new one, not everyone does. I, personally, don't want to play > in an environment when I can't trust that John's foo-1.0.3 and Jane's > foo-1.0.3 and my foo-1.0.3 are the same gem, and I think that's the > sentiment expressed by everybody else in this conversation.
> In this case, you made a simple error, but it was _your_ error, and > you're asking an entire community to accept a process that makes it > easier for you to cover for your errors, while exposing it to a wealth > of insecurity and potential instability. You have at least two > solutions to fix the problem you created. Yank 1.0.0 and release > 1.0.1, or yank 1.0.0, request that it be permanently deleted, and > _then_ re-release it. The latter solution gets you where you want to > get, but with a few extra steps (maybe you'll be more careful next > time), and it doesn't impose your sense about what versions mean on > the rest of us.
Just ran into this issue. I think users should be allowed to remove
gems.
One argument seems to suggest that not being allowed to remove gems
gives some sort of security to the wider community. However as Nick
said 'gem push'ing has allowed overwrites since Day 1'. That means
that with or without a remove command, developers are free to do hokey
things with releases. The sense of security for having no obvious way
to delete is false. Gemcutter has provided mv without rm.
I whole-heartedly agree with the argument that it is not Gemcutter's
place to police developer practices. I think that if a developer has
bad practices and you don't like them then don't use their software.
Gemcutter hosts gems, it does not own them and it should not control
them.
For me the implication that Gemcutter or the wider community owns and
has right to control what I release is a disincentive to share
anything. As I see it I should be able to host a gem on Gemcutter and
know that, as I see fit, I can prevent future downloads from Gemcutter
(never mind that someone could take a previously downloaded gem and do
whatever with it). If GitHub prevented me from removing projects, I
would stop using it. It may sound harsh but if feasible I would not
use Gemcutter for the same reason. My two cents.
- Simon
On Apr 6, 11:44 am, Daniel Parker <dcpar...@gmail.com> wrote:
> It's interesting to me that this is such a heated debate, and reading
> straight through the whole thing I realize that there are two issues
> here that are combining to create 3 separate stances on the topic. So
> let me be a moderator here. The two issues are Good Practice and
> Responsibility.
> Good Practice: Versioning. Please bump your version. Users of your
> code depend on you.
> Responsibility: Users depend on code consistency (versioning), so
> responsibility is important.
> In the area of Good Practice, it looks like everyone agrees that
> versions have a purpose, that for any added functionality and bugfixes
> alike, the version should be bumped. The only difference I see at this
> point is that some would like to be able to overwrite a previous
> version (which may include ALSO adding a new version with the changes)
> in the following cases:
> 1) The current/previous version has a dangerous flaw. (Perhaps other
> libraries or programs depend on specifically this version and this
> dangerous flaw was not discovered until a few versions later.)
> 2) The developer has just pushed the code but realized something
> wasn't right for this deploy. There are sometimes a whole lot of
> things involved in a deploy, such as: making sure we're on the right
> git branch, remembering to update the changelog / history / readme /
> etc, including all files in the manifest (hey, some gems may not be on
> the newest jeweler code yet), possibly generating seed files necessary
> for a new gem version, and more.
> 3) Versions mean something. When the entire reason for a new version
> is nullified by a bug that is identified before any users have
> downloaded the new version, of course I'd rather re-push the same
> version, fixed, than bump the version up again and have a useless (and
> possibly yanked) version in my history.
> 4) Other cases may exist where outside constraints (whether in
> developer's control or not, whether good choices or not) cause re-
> pushing to be the only reasonable option, despite the warnings we all
> agree upon against not bumping a version.
> In the area of Responsibility, we have a heated debate. Who is
> responsible for making the versioning make sense? The users of my gem
> trust me for my code, not gemcutter / rubygems.org. What kind of trust
> are they putting in rubygems.org? We all understand the problem of
> faulty versioning; the question is not "Do we address this problem?"
> but rather "How do we address this problem?" Some have already chosen
> to have rubygems.org police this policy and enforce this "Good
> Practice". The thing is, as 7rans said, "I am the developer and I want
> control over my projects." Let's look at git for a second, as Nick
> brought up: We all understand tagging pretty much the same way as
> versioning. It has the same issues and potential problems we have with
> versioning / re-versioning. But does git tie our hands and prevent us
> from doing "the wrong thing"? No. However, rubygems.org is a service,
> not just a tool in the shed, so they do feel some responsibility for
> this as well. But we have to concede a compromise. Sometimes re-
> pushing is the only good solution. Seldom, VERY seldom, but it is
> true.
> The solution I would propose for this problem is: Make it possible,
> but make it very hard. This discourages doing this as a general
> practice, but allows developers to do it -- only if they really know
> what they're doing.
> My personal policy on this would allow myself to re-push as long as
> there are zero downloads so far, and then allow me to force-re-push
> later for edge cases, such as when I need to fix a horribly dangerous
> bug in a previous version whose api other libraries may depend on. In
> this case I must really know what I'm doing because of course I don't
> want to change the api (that's the reason I need to fix this old
> version in the first place). If I need to fix a horribly dangerous bug
> in an older version, I would not be afraid to push a new version with
> the fix as well. I just may understand the need to fix the bug in a
> previous version as well, because I don't want dangerous code sitting
> there waiting for people to use it just because some other library
> depends on that specific version (for better or for worse, but a
> library that I can't control). To go along with this policy I would
> expect gemcutter to:
> 1) allow free re-pushing as long as the version has zero downloads
> 2) allow re-pushing after downloads only with a --force option,
> accompanied with the SHA for the re-push in order to confirm that I
> really know what I'm doing and that it's worth walking the extra mile
> to do the unconventional and almost-always not-recommended. Could also
> require an interactive confirmation "Are you sure? Y/[N]" with enough
> explanation of the issue and a HIGHLY-NOT-RECOMMENDED message.
> Lastly, for gemcutter to enforce versioning is a strange mismatch of
> trust: it trusts the developer to know what they're doing in releasing
> code in the first place, but it doesn't trust the same developer when
> it comes to versioning that code. Developers are not expected to
> provide their users with the same level of trustworthiness that they
> already provide in the code itself. Again, just a mismatch of trust
> here between gemcutter and developer.
> I agree with you all about the good practice of versioning, but I
> don't like having someone else police what is my responsibility of
> sensible versioning. I also don't like the complete inability to
> provide a fixed version of a deadly older version of a gem that is
> locked in as a dependency of other libraries -- if that were to ever
> happen.
> Requiring the developer to explicitly provide the SHA of a re-push is
> IMO a pretty good way to be sure the developer knows what they're
> doing if they need to re-push. Also a pretty good way of discouraging
> the use of this functionality to the point that nobody would want to
> use it every day. You'd have a re-push rejected by default with a nice
> message that explains the issue and instructs the use of --force and --
> sha=1234567890 to force a re-push.
> - daniel parker -
> On Mar 4, 1:41 am, David Chelimsky <dchelim...@gmail.com> wrote:
> > On Wed, Mar 3, 2010 at 11:12 PM, 7rans <transf...@gmail.com> wrote:
> > >> Sorry if you don't agree, but I think the current approach is by far
> > >> what most people would prefer. That's the beauty of Open Source -
> > >> when it works well, it is a Meritocracy, and the best ideas (as judged
> > >> by the community) rise to the top. That is exactly what happened
> > >> here, and it makes me happy.
> > > Oh yea! I just ran into this tyranny tonight.
> > > Pushing gem to RubyGems.org...
> > > Repushing of gem versions is not allowed.
> > > Please use `gem yank` to remove bad gem releases.
> > > You see I just pushed a gem a few minutes ago. And not 3 seconds after
> > > I pushed it I realized I forgot to make an entry in the HISTORY file
> > > for the release. So I add the entry, takes a whole 3 minutes. And
> > > then, well here I am. I can't make the quick fix. So now what? I'm
> > > supposed to yank it? Why? It still works. Should I contact Nick and
> > > ask him to delete it so I can repush? No, that's right I am supposed
> > > to bump the version. So now there will be two gem files up on the
> > > cloud completely the same except for a small entry in the HISTORY
> > > file. Oh yea, and now I need to add another entry to the HISTORY file
> > > for this new version, eg.
> > > = Release History
> > > == v0.6.0.1
> > > * 1 Enhancement
> > > * Updated this History File
> > > Er... no. I won't be doing that. f* it. I'm just leaving the old
> > > HISTORY file. It's not worth the hassle. The project is in early
> > > development anyway (which makes this restriction even more
> > > ridiculous), and there will likely be a new release in the not too
> > > distant future. So for now too bad for any one reading the HISTORY
> > > file. They can blame meritocracy.
> > There's really no need for this sarcasm. Most of the people involved
> > with this conversation have been extremely patient with you throughout
> > this entire thread, and have gone out of their way to be respectful in
> > spite of the fact that you've been simply unwilling to see the
> > alternate view.
> Just ran into this issue. I think users should be allowed to remove
> gems.
We've thought (and talked) a lot about this. We've decided that `gem yank` covers the most common case, which is keeping folks from discovering and *starting* to use a bad version of your software. Our responsibility goes both ways: We have to consider the consumer of a gem as well as the authors. We're not going to allow authors to casually remove released gems and break consumer deploys.
If a release contains sensitive, malicious, or copyrighted code, ping us on help.rubygems.org. Nick evaluates deletion requests on a case by case basis, and he's very responsive (and more generous than I would be).
I just ran into issue as well. Given the length of this discussion
-- ;) -- there is one case that was overlooked that's frustrating me.
I'm forking actionwebservice to keep it in synch with unsupported
rails versions, and I wanted the version number of my actionwebservice
forks to match the version of rails, actionmailer, activeresrouce,
etc.
I messed up some metadata but didn't notice before I pushed. So, I
thought I'd just "repush" or "yank and repush", but I can't.
The point is that sometimes a version number has a specific meaning --
e.g. it should be equal to the required rails version.
This doesn't discount the alternate view of gems changing behind the
consumers' backs, but I believe the topic has another dimension that
was previously omitted.
--Jonathan
On May 3, 1:17 pm, John Barnette <jbarne...@gmail.com> wrote:
> > Just ran into this issue. I think users should be allowed to remove
> > gems.
> We've thought (and talked) a lot about this. We've decided that `gemyank` covers the most common case, which is keeping folks from discovering and *starting* to use a bad version of your software. Our responsibility goes both ways: We have to consider the consumer of a gem as well as the authors. We're not going to allow authors to casually remove released gems and break consumer deploys.
> If a release contains sensitive, malicious, or copyrighted code, ping us on help.rubygems.org. Nick evaluates deletion requests on a case by case basis, and he's very responsive (and more generous than I would be).
El 30/06/2010, a las 22:15, Jonathan Meeks escribió:
> I just ran into issue as well. Given the length of this discussion > -- ;) -- there is one case that was overlooked that's frustrating me.
> I'm forking actionwebservice to keep it in synch with unsupported > rails versions, and I wanted the version number of my actionwebservice > forks to match the version of rails, actionmailer, activeresrouce, > etc.
> I messed up some metadata but didn't notice before I pushed. So, I > thought I'd just "repush" or "yank and repush", but I can't.
> The point is that sometimes a version number has a specific meaning -- > e.g. it should be equal to the required rails version.
Sounds like a broken practice to me, tying your version number to a version of independent project.
