Release 1.0.0

[tarcieri]

I know there are various issues tagged for a 1.0 release (#208 comes to mind) but perhaps we should evaluate which of those are actually necessary and get to 1.0 sooner than later.

[zanker]

I'm neutral, what does releasing 1.0.0 vs 0.9.10? If people were not going to use the library without a stable version then that would make sense, but I'm not sure anyone really looks at that now. Such as Celluloid which 5 years later is still 0.x.x 😛

[tarcieri]

The main thing would be an acceptance of semantic versioning in making API changes, but also an escape from the sort of perpetual "never 1.0" hell Celluloid is stuck in.

[sferik]

The fact that the 0.9 release has had 6 patch releases in the past month (including two in the past day), makes me think that this library is not yet stable enough for a 1.0.0 release. In my experience, long periods (~6 months) of low-churn indicate that a library is stable enough for a 1.0.0 release. Releasing 1.0.0 prematurely can slow things down a lot.

Much like @zanker, I don’t have any problem with releasing 0.9.10 or 0.10.0. In my view, this library is immature in many ways. It’s still a bit rough around the edges and I’d feel better if it went through a few more iterations pre-1.0.0 and was exercised a bit more before we give it the 1.0.0 blessing and accept the constraints that come along with that.

As for Celluloid, that’s a separate issue. What’s stopping you from releasing 1.0.0 there?

[tarcieri]

As for Celluloid, that’s a separate issue. What’s stopping you from releasing 1.0.0 there?

The endless search for a 1.0 that's sufficiently better than the present to justify being a 1.0 in a project that has gone years without a 1.0. That, and breaking API changes.

I just worry if you put "1.0" up on a pedestal of absolute perfection, there will never be a 1.0 release. I don't think 1.0 should really mean anything more than the API is stable. If it did, there'd never be a 1.0.1 😉

[sferik]

The endless search for a 1.0 that's sufficiently better than the present to justify being a 1.0 in a project that has gone years without a 1.0.

To me, 1.0 doesn’t need to be sufficiently better than the previous release. In fact, I believe the opposite: Ideally, a 1.0 release is nearly identical to the previous 0.x release.

[tarcieri]

Hence my original concern of not making too many changes.

Outstanding deprecations (#208) aside, are there any breaking API changes people still want to make?

[zanker]

I'm good with the API as-is, would rather we get deprecations handled in 1.0 but no issues with bumping to 1.0 after that.

[ixti]

My vote is for holding off of 1.0 release. At least for now. I don't see any bad in releasing 0.10 and then 0.11 if needed. And then release 1.0 only once at least all clean-ups are finished (like options class and such).

[tarcieri]

It'd be good to come to agreement about what cleanups are mandatory for 1.0, IMO.

[zanker]

What's the cleanup needed for the options class? I see #222 which says refactor, but is that an API surface change or internal code.

I think we should sum up any breaking API changes, and make them in 1.0. Anything related to cleaning up code, can be done regardless of semantic version.

[sferik]

Or we could be like Node and jump straight to version 4.0.0?

[zanker]

Could go to 10,000 and beat JRuby

[tarcieri]

I am not opposed to retroactively using TenVer

[sferik]

@tarcieri I think that’s what rake uses.

[tarcieri]

@sferik sounds about right

[tarcieri]

So I am seriously thinking about doing a 1.0.0 release and a lightning talk at RubyConf.

I know there are various things that people would like to "clean up" but that's always the case. They can get cleaned up in 2.0.0, which we can release whenever we want.

Unless there's strong opposition to releasing a 1.0.0, that's what I'd like to do.

[zanker]

👍

[ixti]

They can get cleaned up in 2.0.0, which we can release whenever we want.

Totally agree. So it's from me.

[ixti]

I have moved ALL unresolved issues to milestone v2.0.0
If some of them will be resolved earlier - they will be moved to appropriate milestones (e.g. v1.1.0 etc when it will make sense).

[sferik]

👍

[tarcieri]

Well, RubyConf is nearly upon us and it seems it's agreed to do this.

I think what might actually make sense is to release and announce a 1.0.0.pre at RubyConf, and then actually do a little bit of work to fix a few things prior to an official 1.0 release.

#208 seems relevant.

[zanker]

I'd just tag a 1.0.0 and do any cleanup in a 2.0.0. Realistically versioning is pretty arbitrary and we can start using letters and it's still ok :P

[tarcieri]

@zanker it'd be nice to get rid of the longstanding deprecations prior to release. I think I'll take a stab at that and spin a .pre and see if there's any notable breakages, then we can ship 1.0

[tarcieri]

Well bad news, I caught a cold and don't really feel up to giving a talk :(

On Friday, November 13, 2015, Zachary Anker [email protected]
wrote:

I'd just tag a 1.0.0 and do any cleanup in a 2.0.0. Realistically
versioning is pretty arbitrary and we can start using letters and it's
still ok :P

—
Reply to this email directly or view it on GitHub
#256 (comment).

Tony Arcieri

[tarcieri]

I shipped 1.0.0.pre1 with deprecations removed, and have been using it in my app at work without issues.

@ixti looks like these are the items you tagged as remaining for 1.0?

#259
#264

Any others?

[ixti]

No. Only these ones. Will finish with them before the next week for sure, so 1.0.0 will be released on due date without any issues.

[tarcieri]

@ixti would you still like to fix these before 1.0? I think they can both 1.1+ fixes FWIW

[ixti]

Okay. Let's shift those to 1.1

[tarcieri]

Ok then, well with #281 merged I've released 1.0.0.pre6 and that's it for me. I think we're good to go for 1.0.

[ixti]

[tarcieri]

1.0.0 released! Announcement here:

https://groups.google.com/forum/#!topic/httprb/c26mK1xvJAY