Switch master to 1.0.dev0 (or 0.25.dev0)

[ogrisel]

Or shall we move master to 1.0.dev0?

I can update my PR if we have a consensus.

I am fine with both options. Or we could merge this and rename master later to 1.0.dev0 without releasing 0.25.0.

[ogrisel]

We were not very consistent in the past but I found we often used X.Y.0 for the first major release after an increment in the Y component.

[glemaitre]

From previous discussions, I would tend to go for 1.0

[ogrisel]

Once #18956 is merged I will update the v0.24.rst and index.html files to mirror the changes.

[NicolasHug]

Or shall we move master 1.0.dev0?

No strong opinion for me. I would have liked to get some stuff out of experimental for 1.0 (like the hist-gbdt and SH), but it's NBD.

[adrinjalali]

Marking it as version 1 would definitely motivate me to try to get certain stuff like sample props done, so I'd go for that.

[ogrisel]

Marking it as version 1 would definitely motivate me to try to get certain stuff like sample props done, so I'd go for that.

Ok let's update this PR then.

[adrinjalali]

This change shouldn't be in the same PR as changing the release data, to be able to easily pull it into the release branch once merged.

[ogrisel]

This was already merged in 0.24.X. We can always update if necessary when 0.24.0 final is out.

[adrinjalali]

I see, I guess I have taken them in one PR just for the consistency of the record. Good then :)

[NicolasHug]

So I guess that means we need to change all mentions to 0.25 and 0.26 in our deprecation messages into 1.0 and 1.1?

Ideally we should do that prior to releasing 0.24 to avoid any potential confusion? Also we should indicate somewhere in those messages that 1.0 is just what comes after 0.24 and it's just a renaming, nothing else.

[adrinjalali]

Ideally we should do that prior to releasing 0.24 to avoid any potential confusion? Also we should indicate somewhere in those messages that 1.0 is just what comes after 0.24 and it's just a renaming, nothing else.

At least for my side, I'd rather think of 1.0 as a major release with some backward incompatible changes. So it'd be a bit different from just another release.

[ogrisel]

At least for my side, I'd rather think of 1.0 as a major release with some backward incompatible changes. So it'd be a bit different from just another release.

Personally I would not try to rush backward incompatible changes into 1.0 just for the sake of it. It's just that people have been psychologically disturbed for years that a 10 years old library like scikit-learn still has a version number that starts with a 0.

If we have to introduce breaking changes in 1.0, then ok. If not, that's fine too. If we have to introduce breaking change after 1.X, then we can just decide to release scikit-learn 2.0 for the following release. No big deal.

[ogrisel]

Ideally we should do that prior to releasing 0.24 to avoid any potential confusion? Also we should indicate somewhere in those messages that 1.0 is just what comes after 0.24 and it's just a renaming, nothing else.

Indeed.

[NicolasHug]

At least for my side, I'd rather think of 1.0 as a major release with some backward incompatible changes. So it'd be a bit different from just another release.

I'm with you on this, but we've discussed this in length during a past core dev meeting and it seems most core devs would be unhappy with breaking changes.

It's funny how we're all unclear on who agreed on what, even after a long discussion. I was personally very confused after the meeting (cf #14386 (comment) and following discussion).

(BTW, during the meeting I understood your own position as "let's not break anything" which was doubly confusing to me since you had expressed interest in breaking backward compat before... ;) )

Maybe we need to better frame our meeting discussions

[ogrisel]

My position is that: let's try not to break anything as much as possible as long we can sanely use the 2-release deprecation cycle because scikit-learn is a mature library used by many many developers and I want to be as nice as possible to them.

But I do not completely rule out that some things (e.g. a new way to deal with RNG for instance) might be too complicated or impossible to implement following the 2-release deprecation cycle and will therefore require a breaking change (that should probably be reflected in by an increment of the first component version number, be it 0 to 1 or 1 to 2... with big warnings in the changelog).

But 1.0 does not necessarily have to come with breaking changes. It's just we have used 0.X for too long and some people do not understand why we still have a leading 0.

[agramfort]

+1 for 1.0

[glemaitre]

I think that decide if 1.0 should introduce some breaking changes should not be a blocker here.
However, not deciding 1.0 or 0.25 is actually a blocker for the current release (0.24) (updating the deprecation warning or not) and any PR in master that contains a what's new entry.

From what I can read, everyone is indeed OK with moving forward with 1.0, isn't it?

[NicolasHug]

yes

[glemaitre]

Let's go forward then. I will do a PR to update the FutureWarning