Created

Embed URL

HTTPS clone URL

SSH clone URL

You can clone with HTTPS or SSH.

Download Gist

Summary of ruby-core meeting 2013/12/06

View gist:7875519
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93
new branch format (semver) : ruby_MAJOR_MINOR
 
Handling security releases
 
during ruby 1.8 series
we had dedicated ruby_1_8 branch with no teeny version in branch name
during this time we had to release security fix from this branch
however there were existing unreleased bug fix patches on this branch
our solution was to create a new branch: ruby_1_8_6
and begin maintaining two branches for the 1.8 series
 
additional branches may be added to support cherry-picking security fixes
or releasing security versions
 
releasing teeny versions every 2-3 months
security patches may occur more frequently between version releases
 
semver
 
ABI should remain compatible between MINOR versions
 
MAJOR version is for parties
 
matz concern with teeny > 10
maybe string comparison has bugs, such as:
"2.2.2" <= "2.2.10" #=> false
we can fix this by abanoning strings, the ruby version number can be anything that acts like a string
we will postpone this situation
 
updating tooling
most maintainers use tools from trunk
tools need to remain compatible with backport branches
 
announcement the new semantic versioning policy
 
1.8.7 and 1.9.2 backport policy
We will commit security patches for 1.8.7 and 1.9.2 until June 2014
Backporting tools and development features is ok
Maintaining 1.9.2 for 6 months will not be a heavy job
 
Security release for backport version
hsbt and shyouhei reject 1.8.7 and 1.9.2 backport release
reason against releasing 1.9.2
we dont want any new 1.9.2 tickets
releasing on ruby-lang.org will result in the responsibility of ruby-core to follow up with maintenance afterwards
we don't want to put that responsibility on our team
in 1.9.2 the maintainer is inactive
we are a team, so any issues that arise from a release become everyones problem
its already EOL, we want to encourage upgrades
if someone requests a release for 1.9.2, we can do an official release
 
Add documenation for upgrading to supported versions
Strongly needed, regardless of policy changes
This needs a ticket
 
1.9.3 maintenance
EOL in march when contract ends for usa
additional support may be granted for extended maintenance
encourage commercial support to grant extended maintenance of unsupported versions
an official announcement on this issue is critical
 
maintenance policy
security fixes are priority
maintainers decision for priority of bug fix and security fix
 
maintenance period
3 years supported for minor versions as a team
not contractually obligated
should a branch become toxic, we can EOL within a reasonable time (6-8 months)
 
maintainer commitment on appointment
branch maintainer is not committed to entire maintenance period
a shortened EOL is determined by maintainer activity and team decision
 
ruby-core as a team should be able to support the version for its entire life cycle
not one person is expected to maintain EOL
we need an easy process to change maintainers
we want to avoid sudden death
minimum 6 months period, and at best 3 years
 
ayumin
"ruby-core doesnt need to maintain old branches"
important point is
announcing when we decide to give up on branches
 
specifically define the organization responsible for maintaining a version
ruby-core, vendor, commericial support, etc
 
its the responsiblity of the business party involved to maintain backwards
compatibility
 
encourage commercial support for EOL rubies
this needs a ticket
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.