diff --git a/posts/2019/2019-07-01-SunPy-Releasing.rst b/posts/2019/2019-07-01-SunPy-Releasing.rst new file mode 100644 index 00000000..6be61549 --- /dev/null +++ b/posts/2019/2019-07-01-SunPy-Releasing.rst @@ -0,0 +1,92 @@ +SunPy Release Schedule and Version Numbering +============================================ + +.. post:: June 27, 2019 + :author: Stuart Mumford + :tags: sunpy + :category: Update + + +In this blog post I want to outline how, and more over why, we are going to +number the SunPy releases and when we are going to release them. + +**TLDR**; we are going to move to a 6 month release cadence, with a Long Term +Support (one year of support) release in May and a Short Term Support (6 months +of support) in November. We will increment the major version number for each LTS +release. + + +Background +---------- + +As part of the 1.0 release planning the SunPy developers and the board spent a +long time discussing how we want to version SunPy and what we want to use our +versioning a release schedule to achieve. We went through two major iterations +of this plan, the first can be found in the abandoned PR to the SunPy +Enhancement Proposal repository `#30 `__, +and the second one which was accepted in +`#40 `__. + + +Objectives +---------- + +In moving SunPy out of the 0.y series of releases we knew that our users would +be expecting us to make breaking changes less, and for them to be able to rely +on SunPy for longer. + +We wanted to balance the desire for people to be able to start using SunPy for a +project and be able to see that project through without having to constantly +adjust to many changes in new releases. On the other hand, we wanted to also +allow the development of SunPy to continue without having to delay people +contributing improvements to SunPy because of a strict versioning scheme. + +We also have to consider that, currently, SunPy core is developed entirely by +volunteers, and supporting old versions of the library is a time consuming and +sometimes thankless job. + + +Releases +-------- + +The solution we landed on is to provide a Long Term Support release that we will +support for one year (i.e. until the following LTS release). This gives people +who want stability a release schedule where they get bug fixes for a year. While +also allowing SunPy to do releases on a six month cycle to get new features out +for people to use. + +To make it clear which releases are Long Term Support releases, we will +increment the major version (the first number) for each LTS release. This means +SunPy 1.0 is a LTS release which we will be supporting until the release of 2.0 +in May 2020. + +The all the non-LTS releases between the LTS releases will increment the minor +version number, as there is only one release planned between LTS releases the +normal release number will be 1.0, 1.1, 2.0, 2.1 etc. + +.. image:: sunpy-release-schedule.jpg + + +Deprecations +------------ + +We still expect, and have plans for, changes to many parts of SunPy. We believe +these changes will enable even more people to find SunPy useful in their work. + +To enable people to prepare for changes and to not be in for big surprises when +updating SunPy we will endeavour to provide emit a deprecation warning for any +breaking changes for *one LTS release*. + +The upshot of this is that, if now after 1.0, we want to change something in a +backwards incompatible way we would continue to provide both the old and new +ways until after the 2.0 release. The 2.0 release would emit a deprecation +warning, to give people who go from LTS to LTS a year to update their code +before the next LTS. + + +Conclusion +---------- + +I hope this blog post gives you some insight into how we made this decision and +why, if you have any comments please don't hesitate to get in touch using any of +the usual ways. diff --git a/posts/2019/sunpy-release-schedule.jpg b/posts/2019/sunpy-release-schedule.jpg new file mode 100644 index 00000000..ad0c7e72 Binary files /dev/null and b/posts/2019/sunpy-release-schedule.jpg differ