[ruby-core:53850] An evaluation of 2.0.0 release

Let's look back at 2.0.0 release so that we can do better next time.
I am listing some points.  These are based on developer meeting in Japan:
http://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20130223Japan

Feel free to comment and discuss each point.
If some paticular point seems to be heavily argued, it will be good
to move the item to a separate thread/ticket.


## Refinement is half-baked

Refinement had been discussed immediately before feature
implementation deadline,
and finally it was decided to be an "experimental" feature.
According to Shugo, the biggest reason is because he found the current design
different to matz's expectation immediately before the deadline.

Possible solutions:
  - Continue the discussion
  - Increase real-time meetings to discuss the spec
    - RubyKaigi 2013 (31 May. -- 1 Jun.)
    - RubyConf 2013 (8--10 Nov., maybe too late for 2.1.0)
    - any event or on IRC?


## Preview/RC releases do not gain enough experience

Many bugs of new features are found at the final phase of releasing.
For example,

- MarcAndre found some design issues of lazy (e.g., [#7691])
- I found some corner cases of Module#prepend [#7841--7844]
- matz found some weird behaviors of keyword arguments
- luis found that cross compilation does not work in mingw [#7921]

etc.

Of course, bugs are unavoidable.  But some of them should be easily
found when anyone gives it a try with curiosity.

Possible solutions:
  - Motivate people to try new features
    - provide a tutorial or guide (in matz diary)
    - provide a install-free TryRuby-like platform (by heroku?)


## The "compatible to 1.9" slogan

I think that Matz's slogan that 2.0 should be compatible to 1.9, did work
very well, not only for developers but also for users.
Without this slogan, we couldn't release 2.0 so soon because of excessive
expectations to 2.0.
In addition, this slogan looks to reduce users' mental blocks to migrate
1.9 to 2.0.

But, we can't stay here forever.  This is my personal opinion, but 2.1
should accept minor incompatibilities.


## Timeline

  - Aug. 24th: big feature freeze
  - Oct. 24th: feature freeze
  - Nov. 2nd: preview1
  - Dec. 1st: preview2
  - Dec. 23th: code freeze
  - Jan. 7th: rc1
  - Feb. 8th: rc2 / branch
  - Feb. 24th: p0

In whopping five months (from big feature freeze to branch), any new features
were prohibited to commit, which seemed frustrating for some committers.
Also, "code freeze" was a bad name.  It meant "feature implementation deadline"
in effect.
Furthrmore, it was too short between code freeze and rc1 to make the RC package
stable.
Some committers insisted that "code freeze" imply making a branch.

Possible solution: A new release schedule template

http://bugs.ruby-lang.org/projects/ruby/wiki/ReleaseEngineeringMemo

  - reduced the duration between feature freeze and code freeze:
    5 months -> 2 months
  - splited feature implementation deadline and code freeze


## Announcement to committers

Many committers overlooked my announcements about release schedule/management.

Possible solutions:
  - Make a new mailing list consisting in only committers
  - Show and update the current status of release management
    - so that any committers can know what they should do and what cannot do.
    - the new release schedule template may be helpful
  - Introduce an advanced collaboration apprication


## Unmotivated release manager

2.0 release manager, i.e., I, was not paid for the work.  So once I had
anothor interest (such as IOCCC), the whole release management was stuck.

Possible solutions:
  - Show and update the current status of release management
    - so that any other person can turn over the work
    - the new Release Schedule Template may be helpful
  - Explicitly appoint "assistant release managers"
    - in effect, ko1 and naruse worked as the role in 2.0.0 release
  - Appoint a release manager to full time committer


## Backport regulation to a branch

In principle, backporting anything to a branch requires "ack" from the
release manager/branch maintainers.
But unfortunately, some commits to ruby_2_0_0 branch were done without ack.
Also, some committers were confused about how to backport.

Possible solutions:
  - Only release manager/branch maintainers are allowed to backport.
    - any non-acked commits should be automatically reverted


## Release announcement

I focused on writing and reviewing release announcements.

I hope that this motivated and facilitated people to migrate to 2.0,
though I'm not sure if it was actually effective or not.
But at least, some media seemed to use the announcement to write their
articles.

In [ruby-core:52723], Marc-Andre suggested to improve NEWS rather than the
annnouncement.
This is my personal opinion, but the announcement should include selected
appeal points such as new features and important improvements so that
unfamiliar people can understand them easily.
Of course, I think that it is another important issue to improve the NEWS file.

I regret special thanks.  It lists only people who implemented big features
and/or who was involved in release management.
I didn't intend to ignore people which worked quite some time on fixing things,
discussing issues and spec, but the special thanks might tell people the wrong
message.

Other small things:
  - I wanted to create migration notes, but couldn't.
  - I wanted to write a tip to build on mac, especially, about broken openssl
    bundled with os.


## My lessons

  - A new Release Schedule Template
    http://bugs.ruby-lang.org/projects/ruby/wiki/ReleaseEngineeringMemo
  - Explicitly appoint "assistant release managers"

I appreciate any opinion and feedback.

Thanks,

-- 
Yusuke Endoh <[e-mail]>