Created
December 9, 2013 16:42
-
-
Save zzak/7875519 to your computer and use it in GitHub Desktop.
Summary of ruby-core meeting 2013/12/06
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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