Skip to content

Conversation

@btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Jan 15, 2016

Todos:

  • add to menus
  • get exact dates from @laanwj

ehm0h2j

@harding
Copy link
Contributor

harding commented Jan 15, 2016

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:

We will provide maintenance "point releases" that provide important bug fixes or new features that cannot wait for the next major version or which we think are better deployed in a minor version where people can adopt them quickly without having to analyze a long changelog (for example, soft-forking code). Point releases will be numbered 0.11.1, 0.11.2, 0.12.1, 0.12.2 etc.

@luke-jr
Copy link
Member

luke-jr commented Jan 15, 2016

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.

@btcdrak
Copy link
Contributor Author

btcdrak commented Jan 15, 2016

@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.

@maflcko
Copy link

maflcko commented Jan 15, 2016

I think 0.8 is already EOL due to being vulnerable to the upnp thing?

@luke-jr
Copy link
Member

luke-jr commented Jan 15, 2016

@btcdrak The phrasing sounds more absolute. But for example, 0.10 will continue to get full support after @laanwj moves on, since I will be taking over maintaining it for a [as of yet undetermined] time.

@luke-jr
Copy link
Member

luke-jr commented Jan 15, 2016

FWIW, 0.8.x de facto ended support 2013-12-09 for v0.8.6.

For 0.9, 2015-05-20 (v0.9.5).

@luke-jr
Copy link
Member

luke-jr commented Jan 15, 2016

@MarcoFalke Sounds likely; I think 0.8 and 0.9 were never patched to fix that.

@maflcko
Copy link

maflcko commented Jan 15, 2016

0.9 received the patch but I didn't check if a new tag was created for gitian builds.

@laanwj
Copy link
Member

laanwj commented Jan 18, 2016

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.

@btcdrak
Copy link
Contributor Author

btcdrak commented Jan 18, 2016

OK I've updated preview image with the latest, taking into account @luke-jr and @laanwj

/cc @harding

@luke-jr
Copy link
Member

luke-jr commented Jan 18, 2016

What is TDB? Shouldn't it be TBD?

@harding
Copy link
Contributor

harding commented Jan 18, 2016

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.

@btcdrak btcdrak force-pushed the eol branch 3 times, most recently from e550a59 to 5de1c42 Compare January 18, 2016 19:21
@btcdrak
Copy link
Contributor Author

btcdrak commented Jan 18, 2016

@harding Yoda! haha 😄

I put a key at the bottom.

@btcdrak
Copy link
Contributor Author

btcdrak commented Jan 21, 2016

Was discussed at meeting today http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/21#l1453404632.0

@maflcko
Copy link

maflcko commented Jan 21, 2016

I missed the meeting but the tl;dr:

19:40:29 sipa> final release of 0.X means EOL of 0.(X-2)

Copy link

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)

@laanwj
Copy link
Member

laanwj commented Feb 4, 2016

ACK

When there is no extension, should end with trailing slash
@btcdrak
Copy link
Contributor Author

btcdrak commented Feb 4, 2016

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.

btcdrak added a commit that referenced this pull request Feb 4, 2016
Initial Software EOL policy
@btcdrak btcdrak merged commit 511727e into bitcoin-core:gh-pages Feb 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants