Hey folks, thanks to some great work from John Trupiano we now have gem yank live on the site. I need to work on the API/Gem documentation on the site and help.rubygems, but it takes every concern we had during our previous discussions into account.
* yanked gems are de-indexed but still available for download. example: http://staging.rubygems.org/gems/bills/versions/0.0.1 * if people still need their gems removed permanently from the site we can do that, just with a support request. * once all versions of a gem have been de-indexed, the namespace goes up for grabs from the next user to push to it.
To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter --pre). Any feedback would be appreciated.
On Mar 1, 12:20 am, Nick Quaranto <n...@quaran.to> wrote:
> Hey folks, thanks to some great work from John Trupiano we now have gem yank > live on the site. I need to work on the API/Gem documentation on the site > and help.rubygems, but it takes every concern we had during our previous > discussions into account.
> * yanked gems are de-indexed but still available for download. example:http://staging.rubygems.org/gems/bills/versions/0.0.1 > * if people still need their gems removed permanently from the site we can > do that, just with a support request. > * once all versions of a gem have been de-indexed, the namespace goes up for > grabs from the next user to push to it.
> To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter > --pre). Any feedback would be appreciated.
Hi Nick,
Can you explain the difference between "de-indexed" and "deleted"?
De-indexed means that it won't show up in gem search/install/etc. The gem is still available for download from S3 though. Deleted means really, truly, actually, certainly gone.
I recorded a screencast that we'll make available in the next couple of days that will demonstrate this.
On Mon, Mar 1, 2010 at 8:10 AM, 7rans <transf...@gmail.com> wrote:
> On Mar 1, 12:20 am, Nick Quaranto <n...@quaran.to> wrote: > > Hey folks, thanks to some great work from John Trupiano we now have gem > yank > > live on the site. I need to work on the API/Gem documentation on the site > > and help.rubygems, but it takes every concern we had during our previous > > discussions into account.
> > * yanked gems are de-indexed but still available for download. example: > http://staging.rubygems.org/gems/bills/versions/0.0.1 > > * if people still need their gems removed permanently from the site we > can > > do that, just with a support request. > > * once all versions of a gem have been de-indexed, the namespace goes up > for > > grabs from the next user to push to it.
> > To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter > > --pre). Any feedback would be appreciated.
> Hi Nick,
> Can you explain the difference between "de-indexed" and "deleted"?
On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote:
> Hey folks, thanks to some great work from John Trupiano we now have gem yank > live on the site. I need to work on the API/Gem documentation on the site > and help.rubygems, but it takes every concern we had during our previous > discussions into account.
> * yanked gems are de-indexed but still available for download. example:http://staging.rubygems.org/gems/bills/versions/0.0.1 > * if people still need their gems removed permanently from the site we can > do that, just with a support request. > * once all versions of a gem have been de-indexed, the namespace goes up for > grabs from the next user to push to it.
> To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter > --pre). Any feedback would be appreciated.
Is there a means of un-yanking a yanked gem? Would it just be re- pushing it?
> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: > > Hey folks, thanks to some great work from John Trupiano we now have gem > yank > > live on the site. I need to work on the API/Gem documentation on the site > > and help.rubygems, but it takes every concern we had during our previous > > discussions into account.
> > * yanked gems are de-indexed but still available for download. example: > http://staging.rubygems.org/gems/bills/versions/0.0.1 > > * if people still need their gems removed permanently from the site we > can > > do that, just with a support request. > > * once all versions of a gem have been de-indexed, the namespace goes up > for > > grabs from the next user to push to it.
> > To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter > > --pre). Any feedback would be appreciated.
> Is there a means of un-yanking a yanked gem? Would it just be re- > pushing it?
David, at this time, yes that will suit your purposes. Though for what it's worth I'm not exactly a fan of how it works at this time. Nick and I talked about adding a -f option that you'd have to pass to overwrite a gem release, but that has not been implemented yet.
On Mon, Mar 1, 2010 at 7:34 AM, John Trupiano <jtrupi...@gmail.com> wrote: > On Mon, Mar 1, 2010 at 4:24 AM, David Chelimsky <dchelim...@gmail.com> > wrote:
>> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: >> > Hey folks, thanks to some great work from John Trupiano we now have gem >> > yank >> > live on the site. I need to work on the API/Gem documentation on the >> > site >> > and help.rubygems, but it takes every concern we had during our previous >> > discussions into account.
>> > * yanked gems are de-indexed but still available for download. >> > example:http://staging.rubygems.org/gems/bills/versions/0.0.1 >> > * if people still need their gems removed permanently from the site we >> > can >> > do that, just with a support request. >> > * once all versions of a gem have been de-indexed, the namespace goes up >> > for >> > grabs from the next user to push to it.
>> > To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter >> > --pre). Any feedback would be appreciated.
>> Is there a means of un-yanking a yanked gem? Would it just be re- >> pushing it?
> David, at this time, yes that will suit your purposes. Though for what it's > worth I'm not exactly a fan of how it works at this time. Nick and I talked > about adding a -f option that you'd have to pass to overwrite a gem release, > but that has not been implemented yet.
I think overwriting an existing release is a bad idea. Imagine the confusion when people say they're using foo-1.0.3, but some have the version released in January and the others in March.
I haven't looked at the code related to yanking, but if whatever bit is getting flipped is outside the gem file, I'd like a means of flipping it back while keeping the existing gem as/is. Reasonable? Doable?
> On Mon, Mar 1, 2010 at 7:34 AM, John Trupiano <jtrupi...@gmail.com> wrote: > > On Mon, Mar 1, 2010 at 4:24 AM, David Chelimsky <dchelim...@gmail.com> > > wrote:
> >> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: > >> > Hey folks, thanks to some great work from John Trupiano we now have > gem > >> > yank > >> > live on the site. I need to work on the API/Gem documentation on the > >> > site > >> > and help.rubygems, but it takes every concern we had during our > previous > >> > discussions into account.
> >> > * yanked gems are de-indexed but still available for download. > >> > example:http://staging.rubygems.org/gems/bills/versions/0.0.1 > >> > * if people still need their gems removed permanently from the site we > >> > can > >> > do that, just with a support request. > >> > * once all versions of a gem have been de-indexed, the namespace goes > up > >> > for > >> > grabs from the next user to push to it.
> >> > To play with it you'll need gemcutter 0.5.0.pre (gem install gemcutter > >> > --pre). Any feedback would be appreciated.
> >> Is there a means of un-yanking a yanked gem? Would it just be re- > >> pushing it?
> > David, at this time, yes that will suit your purposes. Though for what > it's > > worth I'm not exactly a fan of how it works at this time. Nick and I > talked > > about adding a -f option that you'd have to pass to overwrite a gem > release, > > but that has not been implemented yet.
> I think overwriting an existing release is a bad idea. Imagine the > confusion when people say they're using foo-1.0.3, but some have the > version released in January and the others in March.
> I haven't looked at the code related to yanking, but if whatever bit > is getting flipped is outside the gem file, I'd like a means of > flipping it back while keeping the existing gem as/is. Reasonable? > Doable?
On Mon, Mar 1, 2010 at 7:41 AM, John Trupiano <jtrupi...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 8:37 AM, David Chelimsky <dchelim...@gmail.com> > wrote:
>> On Mon, Mar 1, 2010 at 7:34 AM, John Trupiano <jtrupi...@gmail.com> wrote: >> > On Mon, Mar 1, 2010 at 4:24 AM, David Chelimsky <dchelim...@gmail.com> >> > wrote:
>> >> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: >> >> > Hey folks, thanks to some great work from John Trupiano we now have >> >> > gem >> >> > yank >> >> > live on the site. I need to work on the API/Gem documentation on the >> >> > site >> >> > and help.rubygems, but it takes every concern we had during our >> >> > previous >> >> > discussions into account.
>> >> > * yanked gems are de-indexed but still available for download. >> >> > example:http://staging.rubygems.org/gems/bills/versions/0.0.1 >> >> > * if people still need their gems removed permanently from the site >> >> > we >> >> > can >> >> > do that, just with a support request. >> >> > * once all versions of a gem have been de-indexed, the namespace goes >> >> > up >> >> > for >> >> > grabs from the next user to push to it.
>> >> > To play with it you'll need gemcutter 0.5.0.pre (gem install >> >> > gemcutter >> >> > --pre). Any feedback would be appreciated.
>> >> Is there a means of un-yanking a yanked gem? Would it just be re- >> >> pushing it?
>> > David, at this time, yes that will suit your purposes. Though for what >> > it's >> > worth I'm not exactly a fan of how it works at this time. Nick and I >> > talked >> > about adding a -f option that you'd have to pass to overwrite a gem >> > release, >> > but that has not been implemented yet.
>> I think overwriting an existing release is a bad idea. Imagine the >> confusion when people say they're using foo-1.0.3, but some have the >> version released in January and the others in March.
>> I haven't looked at the code related to yanking, but if whatever bit >> is getting flipped is outside the gem file, I'd like a means of >> flipping it back while keeping the existing gem as/is. Reasonable? >> Doable?
> Certainly doable. What does the API look like? > gem unyank? > gem yank --undo?
I'd prefer a flag on "gem yank" over a new sub-command, so --undo is my pref of those two. Other options:
gem yank --revert gem yank --rollback
I'm sure there are others - looking for a name that would feel familiar to users. Maybe --undo is the clearest option. WDYT?
Just a heads up, gem push'ing has allowed overwrites since Day 1 and it hasn't really been a problem. I think overwriting a release is a bad idea as well, but sometimes people just forget to fill in some metadata or add one needed file and they don't want to bump the version. We already depend on the library author to be smart about this and it's worked fine.
-Nick
On Mon, Mar 1, 2010 at 8:44 AM, David Chelimsky <dchelim...@gmail.com>wrote:
> On Mon, Mar 1, 2010 at 7:41 AM, John Trupiano <jtrupi...@gmail.com> wrote:
> > On Mon, Mar 1, 2010 at 8:37 AM, David Chelimsky <dchelim...@gmail.com> > > wrote:
> >> On Mon, Mar 1, 2010 at 7:34 AM, John Trupiano <jtrupi...@gmail.com> > wrote: > >> > On Mon, Mar 1, 2010 at 4:24 AM, David Chelimsky <dchelim...@gmail.com
> >> > wrote:
> >> >> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: > >> >> > Hey folks, thanks to some great work from John Trupiano we now have > >> >> > gem > >> >> > yank > >> >> > live on the site. I need to work on the API/Gem documentation on > the > >> >> > site > >> >> > and help.rubygems, but it takes every concern we had during our > >> >> > previous > >> >> > discussions into account.
> >> >> > * yanked gems are de-indexed but still available for download. > >> >> > example:http://staging.rubygems.org/gems/bills/versions/0.0.1 > >> >> > * if people still need their gems removed permanently from the site > >> >> > we > >> >> > can > >> >> > do that, just with a support request. > >> >> > * once all versions of a gem have been de-indexed, the namespace > goes > >> >> > up > >> >> > for > >> >> > grabs from the next user to push to it.
> >> >> > To play with it you'll need gemcutter 0.5.0.pre (gem install > >> >> > gemcutter > >> >> > --pre). Any feedback would be appreciated.
> >> >> Is there a means of un-yanking a yanked gem? Would it just be re- > >> >> pushing it?
> >> > David, at this time, yes that will suit your purposes. Though for > what > >> > it's > >> > worth I'm not exactly a fan of how it works at this time. Nick and I > >> > talked > >> > about adding a -f option that you'd have to pass to overwrite a gem > >> > release, > >> > but that has not been implemented yet.
> >> I think overwriting an existing release is a bad idea. Imagine the > >> confusion when people say they're using foo-1.0.3, but some have the > >> version released in January and the others in March.
> >> I haven't looked at the code related to yanking, but if whatever bit > >> is getting flipped is outside the gem file, I'd like a means of > >> flipping it back while keeping the existing gem as/is. Reasonable? > >> Doable?
> > Certainly doable. What does the API look like? > > gem unyank? > > gem yank --undo?
> I'd prefer a flag on "gem yank" over a new sub-command, so --undo is > my pref of those two. Other options:
> gem yank --revert > gem yank --rollback
> I'm sure there are others - looking for a name that would feel > familiar to users. Maybe --undo is the clearest option. WDYT?
> On Mon, Mar 1, 2010 at 8:44 AM, David Chelimsky <dchelim...@gmail.com>wrote:
>> On Mon, Mar 1, 2010 at 7:41 AM, John Trupiano <jtrupi...@gmail.com> >> wrote:
>> > On Mon, Mar 1, 2010 at 8:37 AM, David Chelimsky <dchelim...@gmail.com> >> > wrote:
>> >> On Mon, Mar 1, 2010 at 7:34 AM, John Trupiano <jtrupi...@gmail.com> >> wrote: >> >> > On Mon, Mar 1, 2010 at 4:24 AM, David Chelimsky < >> dchelim...@gmail.com> >> >> > wrote:
>> >> >> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: >> >> >> > Hey folks, thanks to some great work from John Trupiano we now >> have >> >> >> > gem >> >> >> > yank >> >> >> > live on the site. I need to work on the API/Gem documentation on >> the >> >> >> > site >> >> >> > and help.rubygems, but it takes every concern we had during our >> >> >> > previous >> >> >> > discussions into account.
>> >> >> > * yanked gems are de-indexed but still available for download. >> >> >> > example:http://staging.rubygems.org/gems/bills/versions/0.0.1 >> >> >> > * if people still need their gems removed permanently from the >> site >> >> >> > we >> >> >> > can >> >> >> > do that, just with a support request. >> >> >> > * once all versions of a gem have been de-indexed, the namespace >> goes >> >> >> > up >> >> >> > for >> >> >> > grabs from the next user to push to it.
>> >> >> > To play with it you'll need gemcutter 0.5.0.pre (gem install >> >> >> > gemcutter >> >> >> > --pre). Any feedback would be appreciated.
>> >> >> Is there a means of un-yanking a yanked gem? Would it just be re- >> >> >> pushing it?
>> >> > David, at this time, yes that will suit your purposes. Though for >> what >> >> > it's >> >> > worth I'm not exactly a fan of how it works at this time. Nick and I >> >> > talked >> >> > about adding a -f option that you'd have to pass to overwrite a gem >> >> > release, >> >> > but that has not been implemented yet.
>> >> I think overwriting an existing release is a bad idea. Imagine the >> >> confusion when people say they're using foo-1.0.3, but some have the >> >> version released in January and the others in March.
>> >> I haven't looked at the code related to yanking, but if whatever bit >> >> is getting flipped is outside the gem file, I'd like a means of >> >> flipping it back while keeping the existing gem as/is. Reasonable? >> >> Doable?
>> > Certainly doable. What does the API look like? >> > gem unyank? >> > gem yank --undo?
>> I'd prefer a flag on "gem yank" over a new sub-command, so --undo is >> my pref of those two. Other options:
>> gem yank --revert >> gem yank --rollback
>> I'm sure there are others - looking for a name that would feel >> familiar to users. Maybe --undo is the clearest option. WDYT?
>> > -John
Nick, what do you think about un-yanking though? Or is your thought that because we support re-releasing we don't need to add an explicit option to the API?
On Mon, Mar 1, 2010 at 9:44 AM, John Trupiano <jtrupi...@gmail.com> wrote: > On Mon, Mar 1, 2010 at 8:44 AM, David Chelimsky <dchelim...@gmail.com>wrote:
>>> On Mon, Mar 1, 2010 at 7:41 AM, John Trupiano <jtrupi...@gmail.com> >>> wrote:
>>> > On Mon, Mar 1, 2010 at 8:37 AM, David Chelimsky <dchelim...@gmail.com> >>> > wrote:
>>> >> On Mon, Mar 1, 2010 at 7:34 AM, John Trupiano <jtrupi...@gmail.com> >>> wrote: >>> >> > On Mon, Mar 1, 2010 at 4:24 AM, David Chelimsky < >>> dchelim...@gmail.com> >>> >> > wrote:
>>> >> >> On Feb 28, 11:20 pm, Nick Quaranto <n...@quaran.to> wrote: >>> >> >> > Hey folks, thanks to some great work from John Trupiano we now >>> have >>> >> >> > gem >>> >> >> > yank >>> >> >> > live on the site. I need to work on the API/Gem documentation on >>> the >>> >> >> > site >>> >> >> > and help.rubygems, but it takes every concern we had during our >>> >> >> > previous >>> >> >> > discussions into account.
>>> >> >> > * yanked gems are de-indexed but still available for download. >>> >> >> > example:http://staging.rubygems.org/gems/bills/versions/0.0.1 >>> >> >> > * if people still need their gems removed permanently from the >>> site >>> >> >> > we >>> >> >> > can >>> >> >> > do that, just with a support request. >>> >> >> > * once all versions of a gem have been de-indexed, the namespace >>> goes >>> >> >> > up >>> >> >> > for >>> >> >> > grabs from the next user to push to it.
>>> >> >> > To play with it you'll need gemcutter 0.5.0.pre (gem install >>> >> >> > gemcutter >>> >> >> > --pre). Any feedback would be appreciated.
>>> >> >> Is there a means of un-yanking a yanked gem? Would it just be re- >>> >> >> pushing it?
>>> >> > David, at this time, yes that will suit your purposes. Though for >>> what >>> >> > it's >>> >> > worth I'm not exactly a fan of how it works at this time. Nick and >>> I >>> >> > talked >>> >> > about adding a -f option that you'd have to pass to overwrite a gem >>> >> > release, >>> >> > but that has not been implemented yet.
>>> >> I think overwriting an existing release is a bad idea. Imagine the >>> >> confusion when people say they're using foo-1.0.3, but some have the >>> >> version released in January and the others in March.
>>> >> I haven't looked at the code related to yanking, but if whatever bit >>> >> is getting flipped is outside the gem file, I'd like a means of >>> >> flipping it back while keeping the existing gem as/is. Reasonable? >>> >> Doable?
>>> > Certainly doable. What does the API look like? >>> > gem unyank? >>> > gem yank --undo?
>>> I'd prefer a flag on "gem yank" over a new sub-command, so --undo is >>> my pref of those two. Other options:
>>> gem yank --revert >>> gem yank --rollback
>>> I'm sure there are others - looking for a name that would feel >>> familiar to users. Maybe --undo is the clearest option. WDYT?
>>> > -John
> Nick, what do you think about un-yanking though? Or is your thought that > because we support re-releasing we don't need to add an explicit option to > the API?
On Mon, Mar 1, 2010 at 9:46 AM, Nick Quaranto <n...@quaran.to> wrote: > I don't really see a need for an undo flag if `gem push` essentially acts > the same. In fact, if you did add it in, that's all it should really do.
> Well I think the issue is that re-pushing actually releases new code.
David is asking about just flipping the indexed bit, which I think is an important distinction.
On Mon, Mar 1, 2010 at 8:53 AM, John Trupiano <jtrupi...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 9:46 AM, Nick Quaranto <n...@quaran.to> wrote:
>> I don't really see a need for an undo flag if `gem push` essentially acts >> the same. In fact, if you did add it in, that's all it should really do.
> Well I think the issue is that re-pushing actually releases new code. David > is asking about just flipping the indexed bit, which I think is an important > distinction.
Yes it is. It would be much safer if it just flipped the bit.
So this would start an overall policy change that wasn't in place before that would prevent minor changes to the gem or gemspec. Gem yank is already gem push --undo as well. I guess since pushing a new version is ridiculously fast this policy could be enforced, but I feel that it might cause more headaches.
On Mon, Mar 1, 2010 at 9:57 AM, David Chelimsky <dchelim...@gmail.com>wrote:
> On Mon, Mar 1, 2010 at 8:53 AM, John Trupiano <jtrupi...@gmail.com> wrote:
> > On Mon, Mar 1, 2010 at 9:46 AM, Nick Quaranto <n...@quaran.to> wrote:
> >> I don't really see a need for an undo flag if `gem push` essentially > acts > >> the same. In fact, if you did add it in, that's all it should really do.
> > Well I think the issue is that re-pushing actually releases new code. > David > > is asking about just flipping the indexed bit, which I think is an > important > > distinction.
> Yes it is. It would be much safer if it just flipped the bit.
I need to mull this over a bit more, but I think this could be acceptable...
1) Gem yank allows you to quickly 'undo' a release. Since this wasn't possible before, you usually had to repush or ask us to remove it manually. 2) You're not going to run out of version numbers, and pushing is ridiculously fast. 3) We could take a SHA of the incoming .gem, and make sure on a new gem push that SHA hasn't been pushed, thereby enforcing atomic versions. 4) On a 'repush' we could display a message saying why and telling the user to bump the patch version, and the command to yank that version if need be.
On Mon, Mar 1, 2010 at 10:22 AM, Nick Quaranto <n...@quaran.to> wrote: > So this would start an overall policy change that wasn't in place before > that would prevent minor changes to the gem or gemspec. Gem yank is already > gem push --undo as well. I guess since pushing a new version is ridiculously > fast this policy could be enforced, but I feel that it might cause more > headaches.
> On Mon, Mar 1, 2010 at 9:57 AM, David Chelimsky <dchelim...@gmail.com>wrote:
>> On Mon, Mar 1, 2010 at 8:53 AM, John Trupiano <jtrupi...@gmail.com> >> wrote:
>> > On Mon, Mar 1, 2010 at 9:46 AM, Nick Quaranto <n...@quaran.to> wrote:
>> >> I don't really see a need for an undo flag if `gem push` essentially >> acts >> >> the same. In fact, if you did add it in, that's all it should really >> do.
>> > Well I think the issue is that re-pushing actually releases new code. >> David >> > is asking about just flipping the indexed bit, which I think is an >> important >> > distinction.
>> Yes it is. It would be much safer if it just flipped the bit.
On Mon, Mar 1, 2010 at 9:45 AM, Nick Quaranto <n...@quaran.to> wrote: > I need to mull this over a bit more, but I think this could be acceptable... > 1) Gem yank allows you to quickly 'undo' a release. Since this wasn't > possible before, you usually had to repush or ask us to remove it manually. > 2) You're not going to run out of version numbers, and pushing is > ridiculously fast. > 3) We could take a SHA of the incoming .gem, and make sure on a new gem push > that SHA hasn't been pushed, thereby enforcing atomic versions. > 4) On a 'repush' we could display a message saying why and telling the user > to bump the patch version, and the command to yank that version if need be.
>> So this would start an overall policy change that wasn't in place before >> that would prevent minor changes to the gem or gemspec. Gem yank is already >> gem push --undo as well. I guess since pushing a new version is ridiculously >> fast this policy could be enforced, but I feel that it might cause more >> headaches. >> On Mon, Mar 1, 2010 at 9:57 AM, David Chelimsky <dchelim...@gmail.com> >> wrote:
>>> On Mon, Mar 1, 2010 at 8:53 AM, John Trupiano <jtrupi...@gmail.com> >>> wrote:
>>> > On Mon, Mar 1, 2010 at 9:46 AM, Nick Quaranto <n...@quaran.to> wrote:
>>> >> I don't really see a need for an undo flag if `gem push` essentially >>> >> acts >>> >> the same. In fact, if you did add it in, that's all it should really >>> >> do.
>>> > Well I think the issue is that re-pushing actually releases new code. >>> > David >>> > is asking about just flipping the indexed bit, which I think is an >>> > important >>> > distinction.
>>> Yes it is. It would be much safer if it just flipped the bit.
On Mon, Mar 1, 2010 at 10:45 AM, Nick Quaranto <n...@quaran.to> wrote: > I need to mull this over a bit more, but I think this could be > acceptable...
> 3) We could take a SHA of the incoming .gem, and make sure on a new gem > push that SHA hasn't been pushed, thereby enforcing atomic versions.
I don't think this is necessary. As far as I'm concerned, there are no problems associated with the same codebase being released as two different version numbers. The problem occurs when you try to release two different codebases to the same version number. Seems like unnecessary overhead to me.
On Mon, Mar 1, 2010 at 8:45 AM, Nick Quaranto <n...@quaran.to> wrote: > I need to mull this over a bit more, but I think this could be acceptable... > 1) Gem yank allows you to quickly 'undo' a release. Since this wasn't > possible before, you usually had to repush or ask us to remove it manually. > 2) You're not going to run out of version numbers, and pushing is > ridiculously fast. > 3) We could take a SHA of the incoming .gem, and make sure on a new gem push > that SHA hasn't been pushed, thereby enforcing atomic versions. > 4) On a 'repush' we could display a message saying why and telling the user > to bump the patch version, and the command to yank that version if need be.
+1
Good compromise. Yes, versions are unlimited, and if you screwed up the metadata, just bump, re-release, and write down the steps so you don't screw up next time. Allowing people to overwrite a version, for any reason, is a bad idea...
I also like the compromise for deletion. The only way to permanently delete it is to ask you, and even in that case users should still have a .gem file hanging around somewhere that they can republish on their own. As long as there is no re-push of same version, this will work out fine.
Alright, these recent changes have been implemented, gemcutter 0.5.0.pre.2 has been cut with gem yank --undo. Give it a spin, if I don't hear anything in a day or two I'll get a blog post/release announcement out with a February recap.
-Nick
On Mon, Mar 1, 2010 at 10:58 AM, Chad Woolley <thewoolley...@gmail.com>wrote:
> On Mon, Mar 1, 2010 at 8:45 AM, Nick Quaranto <n...@quaran.to> wrote: > > I need to mull this over a bit more, but I think this could be > acceptable... > > 1) Gem yank allows you to quickly 'undo' a release. Since this wasn't > > possible before, you usually had to repush or ask us to remove it > manually. > > 2) You're not going to run out of version numbers, and pushing is > > ridiculously fast. > > 3) We could take a SHA of the incoming .gem, and make sure on a new gem > push > > that SHA hasn't been pushed, thereby enforcing atomic versions. > > 4) On a 'repush' we could display a message saying why and telling the > user > > to bump the patch version, and the command to yank that version if need > be.
> +1
> Good compromise. Yes, versions are unlimited, and if you screwed up > the metadata, just bump, re-release, and write down the steps so you > don't screw up next time. Allowing people to overwrite a version, for > any reason, is a bad idea...
> I also like the compromise for deletion. The only way to permanently > delete it is to ask you, and even in that case users should still have > a .gem file hanging around somewhere that they can republish on their > own. As long as there is no re-push of same version, this will work > out fine.
> On Mon, Mar 1, 2010 at 8:45 AM, Nick Quaranto <n...@quaran.to> wrote: > > I need to mull this over a bit more, but I think this could be acceptable... > > 1) Gem yank allows you to quickly 'undo' a release. Since this wasn't > > possible before, you usually had to repush or ask us to remove it manually. > > 2) You're not going to run out of version numbers, and pushing is > > ridiculously fast. > > 3) We could take a SHA of the incoming .gem, and make sure on a new gem push > > that SHA hasn't been pushed, thereby enforcing atomic versions. > > 4) On a 'repush' we could display a message saying why and telling the user > > to bump the patch version, and the command to yank that version if need be.
> +1
> Good compromise. Yes, versions are unlimited, and if you screwed up > the metadata, just bump, re-release, and write down the steps so you > don't screw up next time. Allowing people to overwrite a version, for > any reason, is a bad idea...
Yea, but it's my "bad" idea, not yours. If I catch a bug within a short period after a new release and I haven't posted any sort of announcement about it I will re-push. It's not that big of a deal, especially for small, fairly new, and not widely used gems.
> I also like the compromise for deletion. The only way to permanently > delete it is to ask you, and even in that case users should still have > a .gem file hanging around somewhere that they can republish on their > own. As long as there is no re-push of same version, this will work > out fine.
This is silly. When a developer wants a version deleted it is b/c HE HAS A DAMN GOOD REASON. And that reason is almost always that the version is BROKEN. As a developer I don't want broken code out there if I can help it. Besides that, except for major projects like Rails, most people just upgrade to newest versions of a gem no matter what. Most old versions soon become a waste of space.
On Tue, Mar 2, 2010 at 12:35 AM, 7rans <transf...@gmail.com> wrote:
> On Mar 1, 10:58 am, Chad Woolley <thewoolley...@gmail.com> wrote: > > On Mon, Mar 1, 2010 at 8:45 AM, Nick Quaranto <n...@quaran.to> wrote: > > > I need to mull this over a bit more, but I think this could be > acceptable... > > > 1) Gem yank allows you to quickly 'undo' a release. Since this wasn't > > > possible before, you usually had to repush or ask us to remove it > manually. > > > 2) You're not going to run out of version numbers, and pushing is > > > ridiculously fast. > > > 3) We could take a SHA of the incoming .gem, and make sure on a new gem > push > > > that SHA hasn't been pushed, thereby enforcing atomic versions. > > > 4) On a 'repush' we could display a message saying why and telling the > user > > > to bump the patch version, and the command to yank that version if need > be.
> > +1
> > Good compromise. Yes, versions are unlimited, and if you screwed up > > the metadata, just bump, re-release, and write down the steps so you > > don't screw up next time. Allowing people to overwrite a version, for > > any reason, is a bad idea...
> Yea, but it's my "bad" idea, not yours. If I catch a bug within a > short period after a new release and I haven't posted any sort of > announcement about it I will re-push. It's not that big of a deal, > especially for small, fairly new, and not widely used gems.
> > I also like the compromise for deletion. The only way to permanently > > delete it is to ask you, and even in that case users should still have > > a .gem file hanging around somewhere that they can republish on their > > own. As long as there is no re-push of same version, this will work > > out fine.
> This is silly. When a developer wants a version deleted it is b/c HE > HAS A DAMN GOOD REASON. And that reason is almost always that the > version is BROKEN. As a developer I don't want broken code out there > if I can help it. Besides that, except for major projects like Rails, > most people just upgrade to newest versions of a gem no matter what. > Most old versions soon become a waste of space.
> Sure, but this is very straightforward. Yank the bad one. Bump the
version. Rebuild it. Then push it. It will be a matter of days I would think before Jeweler and the other libraries out there add this as a single step for you.
This is just proper library management. There's a reason why git will give you a new SHA when you fix that typo (assuming you've already pushed it remotely).
On Mar 2, 6:45 am, John Trupiano <jtrupi...@gmail.com> wrote:
> > This is silly. When a developer wants a version deleted it is b/c HE > > HAS A DAMN GOOD REASON. And that reason is almost always that the > > version is BROKEN. As a developer I don't want broken code out there > > if I can help it. Besides that, except for major projects like Rails, > > most people just upgrade to newest versions of a gem no matter what. > > Most old versions soon become a waste of space.
> Sure, but this is very straightforward. Yank the bad one. Bump the > version. Rebuild it. Then push it.
"bump the version" Huh? That exactly what I just said I did not want to do.
> It will be a matter of days I would > think before Jeweler and the other libraries out there add this as a single > step for you.
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.
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. It isn't a problem or a reflection on you at all. Frequent releases are 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.
> On Mar 2, 6:45 am, John Trupiano <jtrupi...@gmail.com> wrote:
>>> This is silly. When a developer wants a version deleted it is b/c HE >>> HAS A DAMN GOOD REASON. And that reason is almost always that the >>> version is BROKEN. As a developer I don't want broken code out there >>> if I can help it. Besides that, except for major projects like Rails, >>> most people just upgrade to newest versions of a gem no matter what. >>> Most old versions soon become a waste of space.
>> Sure, but this is very straightforward. Yank the bad one. Bump the >> version. Rebuild it. Then push it.
> "bump the version" Huh? That exactly what I just said I did not want > to do.
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.
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?
