Bump version 0.7.0

[junaruga]

Hi @perlun @scepticulous

I want to release next version as 0.7.0 after fixing
#165
#166

Because we updated for many features/issues. I want to release rack-test rack-2.x compatibility version.

How do you think?
Do you have any other issues/PRs to fix until next release?

[perlun]

@junaruga - I think it would be a good idea to release a 0.7.0 version shortly (or perhaps bump it to 1.0.0 at the same time - the project is stable enough anyway, and 1.0.0 indicates that the API is stable and can be relied upon).

@brynary - could you set up me, Jun Aruga and Dennis Sivia as Rubygems maintainers, in addition to yourself? Here are our Rubygems user names:

• perlun
• junaruga
• scepticulous

Thanks in advance.

[junaruga]

@perlun Yeah, I can agree for both 1.0.0 and 0.7.0.
A little bit I prefer 1.0.0 than 0.7.0. :-)

Ah okay, we have to get a permission to set up it for RubyGems.
https://rubygems.org/gems/rack-test

[dennissivia]

I would actually prefer having at least 1 or 2 iterations (minor version bumps) to see if everything aligns with our ideas and then have a 1.0.0 release. We have to be as compatible as possible already, but while working through the issues and PRs we might discover small changes in behaviour like the cookie path example or handling strings instead of enumerables.
So it would be nice to do any of these adjustments before a 1.0.0 bump. But I would also be fine
with 1.0.0 if that is what both of you preferred.

[perlun]

Fine, going with 0.7.0 works for me. Like you say @scepticulous, something might arise that mandates an API change and it's much better to take that before 1.0 in line with SemVer ideas.

So now we just need to get @brynary attention to get the gem permissions sorted out. 😄

[junaruga]

OK, I agree for 0.7.0. :)

[perlun]

Ping @brynary - we would need Rubygems access to get a new version out the door.

[junaruga]

@perlun I sent email to @brynary yesterday. And I got an auto-reply mail from him about that the reply will be delayed due to his schedule. Maybe only for May.

[perlun]

He lags behind sometimes, but he'll get on to it eventually.

[perlun]

Any updates @junaruga @brynary on this one? (Rubygems access)

[junaruga]

Well, no news from my side.

[junaruga]

Memo: What I want to do until next release.

• Removing Thorfile: Removing Thorfile #169 . because I want to use static gemspec file.
• Error at rake docs and whitespace: Error at rake docs and whitespace #182 . Because I may have to do additional things related to rake docs, though I am not sure right now.
• Update history file at once seeing commits on master branch before release.

[perlun]

@brynary any chance you could add us as maintainers? Quoting myself from May 8:

@brynary - could you set up me, Jun Aruga and Dennis Sivia as Rubygems maintainers, in addition > to yourself? Here are our Rubygems user names:

• perlun
• junaruga
• scepticulous

Thanks in advance.

Jun, if you are in email contact with Bryan, you could also send a reminder that way.

[junaruga]

I sent the reminder to him.
Maybe I should not send him mail anymore for a while around for 3 months from now. Actually I did not get a response from him by email.
I appreciate him.

My suggestion is we can decide due date.
For example if we can not get a permission for Rubygem until end of next month, we will release rack-test2.

I think that this kind of time limit decision is normal.
For example as a company's decision.

After 6 months, we may be able to get the permission, and we may be able to release rack-test.
In that case, rack-test2 can be temporary gem.
In that case, I think this situation is still beneficial.

[junaruga]

Or actually Bundler have a feature to get rack-test from github master branch (or specified commit hash?), as rack-test is used as development dependency in almost cases, there is a choice that we will wait as long as we can.

[perlun]

Yes, we can even make it a tagged release and use the git tag in the Gemfile I think. That's a "doable" workaround for now, but it will make it harder for people to install the gem if they are not on a Unix/Linux machine with git available etc.

[junaruga]

@perlun I just knew that we can use tag from Gemfile. Thanks for the information.
Yeah, I think that we still do not have to do the git tag workaround for now.

I think that documenting the way to install unreleased rack-test with branch or ref option, is good enough right now.
I sent PR for that.
#189

[perlun]

@junaruga - since we are now set up as maintainers of the gem on rubygems.org, I think we should bring out a 0.7.0 as soon as possible. Once we have that published and working, we should then move on to release a 1.0.0 as well, to mark the API as "stable".

(Side note: The 0.6.3 version has been downloaded 55,392,242 times. 55 million downloads! That's a pretty amazing work from @brynary et al!)

[junaruga]

Yes, I think so. We should bring it as soon as possible.

At first we merge this History file. #191
Then you or me will work for release.

[junaruga]

The work are great. :) Creating from 0 to 1 is great.
rack-test is very popular package.

[junaruga]

At first we merge this History file. #191

Done.

Then you or me will work for release.

@perlun
Can you release?
Because maybe I do not have a permission to push tag information to rack-test/rack-test directory.

[perlun]

Can you release?
Because maybe I do not have a permission to push tag information to rack-test/rack-test directory.

Try again, I made you an admin on the repo (as well as Bryan). So you should now be able to circumvent the branch protections a bit (use with care 😄).

[junaruga]

@perlun ok thanks. So, if you like, I am going to release. Is it ok?

[junaruga]

Release done!
https://rubygems.org/gems/rack-test

What I did as release.

$ bundle exec thor list
default
-------
thor :build    # Build a rack-test gem
thor :install  # Install the latest built gem
thor :release  # Release the current branch to GitHub and RubyGems.org

release
-------
thor release:gem  # Push the gem to RubyGems.org
thor release:tag  # Tag the gem on the origin server

$ bundle exec thor :build
gem build rack-test.gemspec
  Successfully built RubyGem
  Name: rack-test
  Version: 0.7.0
  File: rack-test-0.7.0.gem

$ ls pkg/rack-test-0.7.0.gem
pkg/rack-test-0.7.0.gem

$ bundle exec thor release:tag
git tag -a v0.7.0 -m 'Tagging v0.7.0'
git push origin v0.7.0
Counting objects: 1, done.
Writing objects: 100% (1/1), 162 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:rack-test/rack-test.git
 * [new tag]         v0.7.0 -> v0.7.0

$ git tag -n
v0.1.0          Tagging v0.1.0
v0.2.0          Tagging 0.2.0
v0.3.0          Tagging 0.3.0
v0.4.0          Tagging 0.4.0
v0.4.1          Regenerated gemspec for version 0.4.1
v0.4.2          Regenerated gemspec for version 0.4.2
v0.5.0          Regenerated gemspec for version 0.5.0
v0.5.1          Tagging v0.5.1
v0.5.2          Tagging v0.5.2
v0.5.3          Tagging v0.5.3
v0.5.4          Tagging v0.5.4
v0.5.5          Tagging v0.5.5
v0.5.6          Tagging v0.5.6
v0.5.7          Tagging v0.5.7
v0.6.0          Tagging v0.6.0
v0.6.1          Tagging v0.6.1
v0.6.2          Tagging v0.6.2
v0.6.3          Tagging v0.6.3
v0.7.0          Tagging v0.7.0

$ bundle exec thor release:gem
gem push pkg/rack-test-0.7.0.gem
Pushing gem to https://rubygems.org...
Successfully registered gem: rack-test (0.7.0)

[perlun]

Thanks @junaruga! I also published the release notes here, so they are easily accessible: https://github.com/rack-test/rack-test/releases/tag/v0.7.0 (I just copied the contents from History.md).

[dennissivia]

I wonder if we should store your runbook somewhere. In a contributing or release makeup file? Nothing fancy but so it would be easy to find for the next time. What do you think? @perlun @junaruga

[perlun]

Add a note about in the README.md, that's how we typically do it at work. Something like this:

How to make a release

• Merge all PRs that should be included in the release.
• Update History.md

$ bundle exec thor :build
$ bundle exec thor release:tag
$ bundle exec thor release:gem

• Copy the contents from History.md (the release in question) to the releases page.

[junaruga]

@perlun Above set of 3 commands is same with bundle exec thor :release in current README.md. Do you like adding the 3 commands to README.md?

[perlun]

Above set of 3 commands is same with bundle exec thor :release in current README.md. Do you like adding the 3 commands to README.md?

Ah, ok. Then I think we're fine with that. (leaving as-is)

[junaruga]

Nothing fancy but so it would be easy to find for the next time. What do you think?

I am positive for adding 3 commands and @perlun 's suggesting document to README.

[perlun]

@junaruga sure, fine with me, just do it and send me the PR.