-
Notifications
You must be signed in to change notification settings - Fork 511
Initial Software EOL policy #37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I think the text about only backporting features to the point releases is not quite correct. My understanding is that we're trying to introduce all new soft forks in point releases (i.e. not in major versions like we did for BIP66). I suggest saying:
|
|
Maintenance end is not a set point. It's more of only soft-guaranteeing they will be maintained until that point, but we may choose to maintain them longer. |
|
@harding It might be better to to focus on what happens procedurally. Consensus changes are always developed in the master branch first. Once they are ready, they are backported to maintenance branches which we will then release as deployable software. The same holds true for bugs which we feel must be released into maintained versions. The fact that we like to introduce softforks in maintained versions first is orthogonal to the process. We do it because it allows primarily allows enterprise users who have different strict QA process for upgrades. I like your text but I think we also need to be careful since technically maintenance version will receive mostly bug fixing and sometimes minor feature additions, as well as soft-forks (primarily because it increases the speed of adoption). We need to be careful not to imply that people should expect new features in the maintenance versions. Would anything I have said lead you to further revise the text? @luke-jr Agree, that is why there's a gap between maint.end and EOL where we would guarantee critical security fixes but doesn't forbid us from adding other fixes at our discretion. The general rule of thumb so far is "maint.end" is shortly after the next major release. @laanwj of course needs to clarify the exact details. |
|
I think 0.8 is already EOL due to being vulnerable to the upnp thing? |
|
FWIW, 0.8.x de facto ended support 2013-12-09 for v0.8.6. For 0.9, 2015-05-20 (v0.9.5). |
|
@MarcoFalke Sounds likely; I think 0.8 and 0.9 were never patched to fix that. |
|
0.9 received the patch but I didn't check if a new tag was created for gitian builds. |
|
New features are only in major versions (there have been some exceptions, but sometimes the line between bugfix and feature is blurred). Minor versions get bugfixes, translation updates, and softforks. I tend to regard the last two major releases as maintained: so at this point 0.10 and 0.11, after the 0.12 release that will be 0.11 and 0.12. Translation on transifex is only open for the last two major releases. The older the major release, the more critical issues have to be to get backported to it, and the more to warrant a new minor release. E.g. in the case of upnp issue, it was backported to 0.9, but no one bothered doing a new minor release. Usually the assumption is that people on such releases will have their own patch sets (hence the upgrading inertia), so don't really benefit from binary releases. There is generally zero interest from gitian builders to build such 'back-releases' anyhow. But indeed, as @luke-jr says, it doesn't depend just on me. It's perfectly OK if luke-jr wants to adopt some release (such as 0.10.x) and maintain it for longer. |
|
What is TDB? Shouldn't it be TBD? |
|
Luke, I believe TDB is the Yoda-speak version of TBD. :-) (Or if you're really dorky, the Ciceroean version.) Nitpick: I suggest that instead of "TBD", we write out "To be determined" or just "Unknown" so people don't have to ponder abbreviations they may not be familiar with. |
e550a59 to
5de1c42
Compare
|
@harding Yoda! haha 😄 I put a key at the bottom. |
|
Was discussed at meeting today http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/21#l1453404632.0 |
|
I missed the meeting but the tl;dr:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this consistent with the table? (0.9 died on 2015-12-31)
|
ACK |
When there is no extension, should end with trailing slash
|
I've talked this over with @laanwj and it's good enough. EOL is a living document and dates will have to be updates as we go along anyway. |
Todos: