Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

RFC: Release schedule #734

Open
effigies opened this issue Mar 1, 2019 · 4 comments
Open

RFC: Release schedule #734

effigies opened this issue Mar 1, 2019 · 4 comments

Comments

@effigies
Copy link
Member

effigies commented Mar 1, 2019

The current release schedule is ad hoc, which mostly follows a pattern that a bug gets fixed or feature gets added, and then several months later people get tired of depending on an unreleased feature and ask for a release. So I'd like to establish a predictable release schedule, while at the same time not artificially inducing churn or overburdening downstream projects with too short of deprecation timelines.

For the level of activity we see, I think quarterly minor releases would be sensible, and a yearly major release would allow us to begin to finally remove components that have been deprecated for years at this point. Major releases will have a minimum one month RC phase.

Bug-fix (micro) releases could continue on an ad hoc basis, on a monthly schedule if there's steady accumulation, shorter in the case of downstream breakage or longer for slow periods.

I'll plan on starting with a minor release (2.4.0) in March or April, and a major release (3.0.0) in September or October.

There's a related discussion to be had about Python 2 support, but perhaps that makes more sense to start another thread?

@nipy/core @nipy/team-nibabel Let me know if you have any reservations (or unreserved support...). I'll also ping @GaelVaroquaux, @pauldmccarthy and @afni-rickr to make sure nilearn, and the Pythonic sides of FMRIB and AFNI get a chance to weigh in. Please tag in anybody else that you think might want to comment.

@yarikoptic Any concerns from a NeuroDebian perspective?

@matthew-brett
Copy link
Member

I like the plan - thanks for writing it up.

@yarikoptic
Copy link
Member

Sounds great to me, thank you!

@effigies
Copy link
Member Author

effigies commented Jun 26, 2019

From the last few months, I think shooting for quarterly feature releases is probably faster than the activity level justifies, so I'm going to update the schedule to every four months. If churn picks up, we can revisit again.

The new targets are:

Release Month Notes
2.5.0 July 2019 Final series with Python 2.7, 3.4 support
3.0.0-rc1 October 2019 API breaking changes
3.0.0 November 2019
3.1.0 March 2020
3.2.0 July 2020 Final series with Python 3.5 support
4.0.0-rc1 October 2020
4.0.0 November 2020

Note that for nibabel 3.2.0, I'm projecting that Python 3.5 will end-of-life in September 2020. The relevant PEP 478 does not have a lifespan statement, but five years from the release of 3.5.0 is is consistent with the stated 3.4, 3.6 and 3.7 deprecation schedules.

@effigies
Copy link
Member Author

To update the table with actual releases and project out through the end of 2020:

Release Month
2.5.0 July 2019
3.0.0-rc1 November 2019
3.0.0 December 2019
3.1.0 April 2020
3.2.0 August 2020
4.0.0-rc1 November 2020
4.0.0 December 2020

See also #803 for Python/Numpy support.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants