Switch master to 1.0.dev0 (or 0.25.dev0) #18958
Conversation
| # X.Y.ZaN # Alpha release | ||
| # X.Y.ZbN # Beta release | ||
| # X.Y.ZrcN # Release Candidate | ||
| # X.Y.Z # Final release |
There was a problem hiding this comment.
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.
|
From previous discussions, I would tend to go for 1.0 |
|
Once #18956 is merged I will update the |
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. |
|
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. |
| @@ -827,3 +830,57 @@ Code and Documentation Contributors | |||
|
|
|||
| Thanks to everyone who has contributed to the maintenance and improvement of | |||
| the project since version 0.23, including: | |||
|
|
|||
| Abo7atm, Adam Spannbauer, Adrin Jalali, adrinjalali, Agamemnon Krasoulis, | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This was already merged in 0.24.X. We can always update if necessary when 0.24.0 final is out.
There was a problem hiding this comment.
I see, I guess I have taken them in one PR just for the consistency of the record. Good then :)
92d734c to
e127514
Compare
|
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. |
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. |
Indeed. |
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 |
|
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 |
|
+1 for 1.0 |
|
I think that decide if 1.0 should introduce some breaking changes should not be a blocker here. From what I can read, everyone is indeed OK with moving forward with 1.0, isn't it? |
|
yes |
|
Let's go forward then. I will do a PR to update the |
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.