Version bumped but not pushed to rubygems
deivid-rodriguez opened this issue · 25 comments
Hi. It seems that there's been active development in this gem lately and you have released a new version 1.0.0. I would like to try it, but it seems you haven't pushed it to rubygems.org so gems dependent on your gem can't upgrade unless we point to your current master.
Salute.
You can try it. Here's how:
git clone https://github.com/rocky/columnize.git
cd columnize
rake test # You do want to test this, right?
rake gem # creates gem file
gem install --local pkg/columnize-0.9.9.gem
If you do install and it works great, let me know and I'll try to make a general 1.0.0 release soon after.
Although without a doubt Martin Davis did a really fantastic job, I still need to make sure this still works with the packages that I know that use this.
Alright! I just thought that, since you had bumped the version number, it was ready to release but you had just forgotten to do it.
I will try it soon and let you know how it goes. Thanks a lot for the good work!!
Hi again. I just tried the last columnize. First I run the test suite: everything passed, sweet. Then I tried created the gem but there was an error because the gemspec filename in the Rakefile seemed incorrect. I corrected that, built and installed the gem. Then I tried it against my gem. Every call to columnize failed due to wrong number of arguments, so I changed every call like this
columnize(my_array, my_width)
to
my_array.columnize(displaywidth: my_width)
and it all went fine. So it looks like, apart from the change in the interface, columnize still works as it should! :)
Hmm... I thought this was going to be totally compatible. Martin?
On Sat, Apr 27, 2013 at 8:23 AM, deivid-rodriguez
notifications@github.comwrote:
Hi again. I just tried the last columnize. First I run the test suite!
Everything passed, sweet. Then I tried created the gem but there was an
error because the gemspec filename in the Rakefile seemed incorrect. I
corrected that, built and installed the gem. Then I tried it against my
gem. Every col to columnize failed due to wrong number of arguments, so I
changed every call like thiscolumnize(my_array, my_width)
to
my_array.columnize(displaywidth; my_width)
and it all went fine.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-17115288
.
Interesting. Calls like Columnize.columnize(my_array, my_width) are working, but including Columnize and then calling columnize(my_array, my_width) is failing. I'll look into why, write some tests, and get this fixed.
Many thanks. I appreciate it.
On Sat, Apr 27, 2013 at 10:02 AM, Martin Davis notifications@github.comwrote:
Interesting. Calls like Columnize.columnize(my_array, my_width) are
working, but including Columnize and then calling columnize(my_array,
my_width) is failing. I'll look into why, write some tests, and get this
fixed.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-17116588
.
Ok, I already see the issue. I made the (wrong) assumption that the module would only be included into classes where it would be used like a method on self and that, if it were to be called as a function, Columnize.columnize would be used. Even though they share a name, Columnize.columnize and Columnize#columnize are two different functions. I can rework Columnize#columnize to make it backwards compatible. But, being the interface idealist/zealot that I am, I think 1.1.0 should perhaps break backwards compatibility. ;)
That's fine: we can plan on 1.1.0 to break backwards compatibitly. There is
other interface junk in there that I had from a while ago before the
options hash that I would like to remove.
Also perhaps in 1.1.0 we can generalize the atom-length calculation
routine. Right now it handles terminal escapes but there is no reason it
couldn't handle other things like HTML markup, e.g. &ndash and > have
length 1.
On Sat, Apr 27, 2013 at 10:16 AM, Martin Davis notifications@github.comwrote:
Ok, I already see the issue. I made the (wrong) assumption that the module
would only be included into classes where it would be used like a method on
self and that, if it were to be called as a function, Columnize.columnize
would be used. Even though they share a name, Columnize.columnize and
Columnize#columnize are two different functions. I can rework
Columnize#columnize to make it backwards compatible. But, being the
interface idealist/zealot that I am, I think 1.1.0 should perhaps break
backwards compatibility. ;)—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-17116782
.
I would, when possible, try to follow semantic versioning: if planning to break backwards compatibility, do it when changing the major version number (0.x.x -> 1.0.0).
Since this is a major version number, is an issue that we've broken backward compatibility? (Can you tell that I really don't want to have to rewrite it? ;)
No no, I'm perfectly fine with it! :)
Ok, I've got the changes checked into a local branch and I'll send the patch to Rocky. Rocky, it's up to you to decide if you want to maintain backwards compatibility (or not!) for this release =)
--Martin
Martin Davis sent a backwards compatibility patch and that's been applied. So I guess the following is for discussion.
Much as I dislike the current API (due to my ineptness), right now I can't release something and break compatibility: the gem has been downloaded about 3 million times and 1.5 million times for this release. See https://rubygems.org/gems/columnize . That's a lot of people to piss off!
I also think it great to follow the semantic versioning guidelines. Again this is also my fault for not having tried to be more cognizant of this before. But even so, the reality though is the gems I've written that require columnize either don't give a minimum version or perhaps use '>='. Others packages may have done the same thing.
So if folks were warned from the start we might have a 1.0 release that breaks compatibility, and if dependencies to columnize were written in such a way to keep thins in mind, it would be fine. But given the way things are now, probably not.
Of course it's not too late to start declaring that an incompatible release is in the works.
Fnally there comes the question of what you want the version to be for the next release to be called. Since we are keeping compatibility, should this stay with 1.0 for the release. Or use 0.4.0 and reserve 1.0 for the first incompatible release? (Otherwise, what, 2.0.0 for the first incompatible release?)
In my view it's all up to you. If you don't care, I'll make some decision. But given mistakes I've made in the past, you might be better off to weigh in on this rather than leave it for me to make a somewhat arbitrary decision.
Semantic versioning says this:
- Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
- Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
So I think it would be fine to release 1.0.0 now and adhere to semantic versioning from now on.
I agree, you should release 1.0.0 with the new API. I don't know the best way to to let people know ahead of time that the public API is changing. However, for your own gems which depend on Columnize, I would make sure that you update the dependencies to add "< 1.0.0" and release a new minor version. It doesn't cover every possible issue, but it should cover the ones that you can do anything about.
waslogic advises:
I would make sure that you update the dependencies to add "< 1.0.0" and release a new minor version.
think you mean 2.0.0, right?
Or, you could release the backward compatible version as 0.9.0 and the other as 1.0.0 (assuming, of course, that you haven't already released them =)
Ok, baring objections that's what we'll do.
Hi @rocky ! So... are you planning on actually releasing a new version?
Eventually, yes. I need to change some tests in the debuggers which break with the API change.
@rocky Any updates?
I apologize for the delay. I'll try to have something out maybe over the weekend. Thanks for keeping on me for this.
Sounds good! :)
Yes, it works! Thanks a lot.