RLS: 0.18.2

[jorisvandenbossche]

It is two months since 0.18.1 is released, and there are already quite a lot of changes in master, so it is time to think about a next release.
Currently, the release is targeted to be 0.18.2.

Personally, I think current master has already more new features and slight API changes than would be expected from a bug-fix release, so my proposal would be to just call it 0.19.0 instead (as also discussed on the dev meeting).
If there is agreement on this, I can do the change this week (not much work, just changing all references of 0.18.2 to 0.19.0 and retargeting the issues).

Besides that, there are two other questions in case of a rename of master to 0.19.0:

• Do we want to release current master as 0.19.0 as is (in the short time, meaning we could tag a release candidate shortly)? Or do we want to give it some more time?
• Do we still want to release a 0.18.2 bugfix release? We could select some bug fixes that are now in master to put in a 0.18.2 release.

[sinhrks]

Personally I prefer 0.18.2 because I haven't sent/prepared PRs initially intended for 0.19 which causes period/sparse API changes. Though it's ok for next time.

[TomAugspurger]

I don't have a strong preference either way. Just want to note that even if we do a 0.19 release now, we can follow up relatively quickly with a 0.20 release if thee are API breaking changes that are ready to go in.

[jorisvandenbossche]

Personally I prefer 0.18.2 because I haven't sent/prepared PRs initially intended for 0.19 which causes period/sparse API changes. Though it's ok for next time.

@sinhrks Do you mean you deliberately limited your PRs on period/sparse to not include API changes, that you otherwise would have made? That could be a reason to not directly release 0.19.0, but give it another month (or as @TomAugspurger says not wait long with 0.20).
In any case, if targeting master as 0.19.0, we probably would want to include some more deprecations so it will take a bit longer.

[jorisvandenbossche]

@sinhrks OK for you? (my last comment)

If no further objections, I will make the change tomorrow.

[sinhrks]

Yes, whichever is OK:)

[jorisvandenbossche]

OK, so the PR replace all occurences of 0.18.2 to 0.19.0 is up, renamed the milestones and adding some of the original issues for 0.19.0 back to that milestone.

Main attention point for the coming days will be when merging already existing PRs that they have to move the whatsnew note.

[jreback]

moved to 0.19.0

[jorisvandenbossche]

There is still the second question from above: Do we still want to release a 0.18.2 bugfix release? We could select some bug fixes that are now in master to put in a 0.18.2 release.

I don't think it would be a lot of work to cherrypick some of the bug fixes into a 0.18.2 release (eg there were some regressions fixed), but of course actually doing the release still takes some work, so question is if it worth it.

[TomAugspurger]

I've been swamped lately, and so might not be able to help with the cherry-picking / release.

How long would we support a hypothetical 0.18.x bug fix branch for? I assume users would be interested in that upfront.

[jreback]

I would say let's skip for 0.18 and pick up the 'backports' for 0.19.0x series.

I also wouldn't maintain them beyond the actual release at all. You can always backport fixes to a new release if you wanted (but this is way too much work to be honest).

e.g. release 0.19.0 in say a month.

Then switch master to 0.20.0 and backport for 0.19.1 (0.19.2), etc.

[jorisvandenbossche]

I also wouldn't support a 0.18.x branch longer than the next major release (that is something we should consider later on, certainlty when there is a possible 1.0, but for 0.18 not needed I think).

But if the final 0.19.0 release would be in eg 2 months, this would just be a way to already push some of the most important bug fixes to users now (eg in a week time), plus give users who would not upgrade directly to 0.19 a release with some bug fixes we already did

[jreback]

The not-upgrade path is to be honest way too much work for an open-source project (meaning providing a release series because people don't want to upgrade). The only real reason to back-port is to provide bug-fix-only timely releases. I think you are going to run into major issues even trying to backport some things.