Skip to content

Instantly share code, notes, and snippets.

@zzak
Created December 9, 2013 16:42
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save zzak/7875519 to your computer and use it in GitHub Desktop.
Save zzak/7875519 to your computer and use it in GitHub Desktop.
Summary of ruby-core meeting 2013/12/06
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