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

Release schedule for 0.17.0 #12624

Closed
laanwj opened this Issue Mar 6, 2018 · 11 comments

Comments

Projects
None yet
7 participants
@laanwj
Copy link
Member

laanwj commented Mar 6, 2018

Here is a proposed release schedule for 0.17.0, the next major release of Bitcoin Core. Like for previous major releases I've aimed for a release 6 months after the last (#11449).

2018-07-02
-----------
- Open Transifex translations for 0.17
- Soft translation string freeze (no large or unnecessary string changes until release)
- Finalize and close translations for 0.15

2018-07-23
-----------
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until release)

2018-08-13
-----------
- Split off `0.17` branch from `master`
- Start RC cycle, tag and release `0.17.0rc1`
- Start merging for 0.18 on master branch

2018-09-08
-----------
- Release 0.17.0 final (aim)

If any specific dates or timeframes are a problem for you, let me know.

@laanwj laanwj added this to the 0.17.0 milestone Mar 6, 2018

@AlexGoldovsky

This comment has been minimized.

Copy link

AlexGoldovsky commented Mar 15, 2018

@laanwj Excuse me, but, What exactly is a good first issue about this?
I'm looking for an issue to start with, but I don't get what should be done here.

@laanwj

This comment has been minimized.

Copy link
Member

laanwj commented Mar 15, 2018

@AlexGoldovsky If you plan on submitting any PRs, it's good to know about the upcoming release schedule.

@thijstriemstra

This comment has been minimized.

Copy link

thijstriemstra commented Mar 16, 2018

Excuse me, but, What exactly is a good first issue about this?

Was thinking the same; sounded like being a release manager as first issue/task would be good.

@fanquake

This comment has been minimized.

Copy link
Member

fanquake commented Mar 16, 2018

@thijstriemstra The "good first issue" label was originally added to release milestones as a bit of "tongue in cheek", however as @laanwj has pointed out, if new contributors are filtering for issues using that label, they will now also see the current release schedule.

@laanwj

This comment has been minimized.

Copy link
Member

laanwj commented Mar 16, 2018

Right - it's a good first issue to read.

@flack

This comment has been minimized.

Copy link
Contributor

flack commented Apr 8, 2018

This discussion about "good first issue" happens on every single one of these release schedule tickets. Maybe it's time to admit defeat and remove it? If I'm a new contributor looking at "good first issues", I'm looking for something to work on. If I want to know when the next release happens, I go to https://github.com/bitcoin/bitcoin/milestones

Thinking a bit further, github milestones support both a due date and a description, so why not use those? The release schedule ticket is not really actionable anyways, so it might be better to simply use the facilities provided by the platform

@laanwj

This comment has been minimized.

Copy link
Member

laanwj commented Apr 8, 2018

@flack

This comment has been minimized.

Copy link
Contributor

flack commented Apr 8, 2018

Sorry, I didn't mean to sound bossy or anything. But seeing how good first issue is supposed to be for new contributors, I thought maybe an outsider's perspective might be helpful. Obviously, do what you think is best, I just find it silly that literally on each of these release tickets it's the same discussion

@laanwj

This comment has been minimized.

Copy link
Member

laanwj commented Apr 9, 2018

Sorry, was a bit grumpy last night and took it out on you. There's a lot of hostile people in this space but you're not one of them and the last thing I want is to chase away new contributors. So yeah I guess, thanks for the input.

As for the "due date" with milestones we could put something there, but it's not clear which date. Probably the feature freeze date is most useful, as it is the intent for developers to target that.

@flack

This comment has been minimized.

Copy link
Contributor

flack commented Apr 13, 2018

One small (and hopefully uncontroversial) change that could be made would be to link this ticket from the milestone's description (i.e. just put in something like "see #12624 for proposed schedule"). It would improve discoverability and you could still keep the tag if you really want to :-)

@mmortal03

This comment has been minimized.

Copy link

mmortal03 commented Oct 8, 2018

Also, shouldn't this one be closed now that 0.17.0 was released?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment