Skip to content

Instantly share code, notes, and snippets.

@zzak zzak/gist:7821769
Created Dec 6, 2013

Embed
What would you like to do?
Summary of ruby-core meeting 2013/12/05
2.1 schedule | http://bugs.ruby-lang.org/versions/27
rc next week (2013-12-8 - 2013-12-14)
rc2 only if major issue found in rc1
make new branch ruby_2_1_0
code freeze
bug fix requires maintainer approval
release on christmas
2.1 maintainer #9215
undecided
naruse maintain 2.1 for 2 months after release
semantic versioning #8835
english: https://gist.github.com/sorah/7803201
japanese: https://gist.github.com/hsbt/7719305
we accept hsbt proposal
starting with 2.1.0
ruby-{MAJOR}.{MINOR}.{TEENY}
major: increased when incompatible change (which cant be released in minor)
"major is for party"
reserved for major events, and special occasion
minor: increased every christmas, may be api incompatible
teeny: security fix, bug fix, which maintains api compatibility
we increase even more than 10 (such as 2.1.11)
released every 2-3 months
matz is concerned about teeny > 10
patch level: commits since last minor release
remains p0
branches
trunk
ruby_{MAJOR}_{MINOR}
keeping using {MAJOR}_{MINOR} branch across TEENY releases
add tags for each release
api compatibility
removing api is incompatible change
removing (STDIO_READ_DATA_PENDING, etc.) for 2.2
incompatible change increases MINOR
ABI
{MAJOR}.{MINOR}.0
try to keep ABI compatibility among same {MAJOR}_{MINOR} release
so TEENY is fixed at 0
retain ABI compatibility across TEENY releases
Pros
Cons
Changes required to tooling
* svn
* backport / merger
Documentation
we need to announce that we will be removing the patch level semantics and use {MAJOR}.{MINOR}.{TEENY}
Maintenance Policy for 1.8.7, 1.9.2 #9216
1.8.7 and 1.9.2 will be supported for security fixes until June 2014
Committers Terence Lee (hone) and Zachary Scott (zzak) will assume maintainership
If we someone is willing to help maintain these versions and can commit to a 6 month maintenance period, we can add more committers.
In the past we have supported vendors who wish to maintain legacy versions
2009 maintenance of ruby 1.8.6 was transfered to Engine Yard
They released 1.8.6-p369
Releasing Backports
As backport maintainer: its ok to release a backport version of ruby for security fixes
Security releases only
Ok even after EOL if maintained
Maintenance Policy for 1.9.3 #9217
1.9.3 maintenance is a commission enterprise of ruby asscociation.
Maintained for security fixes until march
Additional 3 month security fix maintenance period may be supported by usa
Maintenance Policy for >= 2.1.0 #9215
After 2.1.0
2.0.0:
normal maintenance until february
1 year security fix support
Each MINOR release starting with 2.1.0
2 years normal maintenance
3 years security fix support
A more routine process will improve user expectations
Each release manager decides the roadmap for their version
Absolute schedule and maintenace plan is hard
Policy announcements #9219
I will write:
maintenance policy announcement for 2.1.0 announcement
news announcement for www.ruby-lang.org
mrkn has created:
bugs.ruby-lang.org/attachments/4091/ruby_maintenance_scheme.pdf
Maintainer appointment and discharge #9218
If branch maintainer becomes inactive
nobu can help as global maintainer (patch monster)
we will decide the next maintainer, ask them for assignment
Anyone can replace release manager role, should the manager become inactive
Every issue can escalate to matz
Maybe we need to replace matz sometime
We should fire matz
Asking to declare maintainence period when accepting branch role is rejected
nagachika:
I never publish maintenance period for 2.0.0. I thought I can maintain it
for 2 years in "normal maintenance mode" and then turn into "security only
maintenance mode".
now I feel a little hard to keep current pace of activity for maintenance
for 2.0.0.
usa may begin maintainence of 2.0.0 in march
GC merits and documentation in README.EXT #8962
matz ordered koichi to write documentation
(nobu's children screaming loudly)
extension authors need a guide to implement WB
writing extension using WB is difficult
encouraging use of WB will cause serious problems
koichi will guide them to write extension without using WB
we only implement WB internally
advanced extension authors should refer to internal implementation of WB usage
direct them to source examples, such as Array which uses WB for implementing their extension
"its ok to be shady"
zzak will help
Matsuda commits typo patches
He is typo monster
Forgot [DOC] tag in ChangeLog!
Martin Duerst commits too!
https://github.com/ruby/ruby/commit/737c7d8
Terence joins call:
Provides feedback on maintainer appointment and discharge process
People get stuck maintaining something beyond burnout and exhaustion
Implement process to "pass the torch" while something is still maintained
We discussed library maintainership
2 years of normal maintenance is a lot to ask of one person
A single person should be supported during this process
Should someone decide to step down
A process to promote various people to support maintenance
Include an election process to decide the new maintainer
ruby-core approval with matz decision
Should maintainer go inactive
Discussion takes place to begin election process
Matz supports adding new committers to support maintenance
During normal maintenance period, encourages use of old version
We should support a replacement process
Encourage other committers to support maintenance
Feedback on backport versions for security fixes
downstream vendors support backport versions internally
we want to externalize this process
railslts.com
we have approval to maintain backport versions upstream
releasing backport versions is ok as maintainers
We plan to discuss with shyouhei about releasing 1.8.7
Error hiding #7688
In some cases comparable#== will return false, instead of propagating the exception
It has improved in some cases, but some exceptions are still hidden
Matz is undecided
this change is experimental, so we can try and see if there are any problems
we cant start experiementing after 2.1 is released
Noone took notes, we had no summary :(
I rewatched the video and wrote this summary, since most discussion was in English
The japanese discussion for SemVer was translated on gist thanks to sora
Matsuda will propose gemifying the stdlib at the next meeting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.