A Release Schedule and Version Numbering Scheme for SunPy by Cadair · Pull Request #40 · sunpy/sunpy-SEP

Cadair · 2019-01-30T17:29:25Z

Rendered

fixes #39

Update SEP-0009.md Update SEP-0009.md

Update SEP-0009.md

mbobra · 2019-01-30T17:50:03Z

Nice!! Do people think it is a good idea to mention papers? E.g.:

All effort will be made to publish a paper coincident with every / every other LTS release.

dpshelio · 2019-01-31T21:50:10Z

If I understand correctly we are not preventing API changes in minor versions (like with semantic versioning), will 1.2.0 be backwards compatible with 1.0.0?
I also don't see much of a point of changing versioning number every year, mostly if not big changes are in place. It can, unless forcing updates as the browsers do with pop-ups, the opposite effect on our users, to keep them all not updating for fears to things to break. If we are going to do this we really need to educate our users beyond just this SEP and releases notes. That won't be an easy task.

Though I agree with @mbobra, that papers would be nice, I don't think one per LTS, with the proposed calendar, is doable. Also if there are no "new" things worth to tell about as it's possible that there are no even API changes. I would aim for all the odd/even versions instead.

ehsteve · 2019-03-12T14:39:29Z

FYI @mbobra @dpshelio I've made some suggested edits and made a PR to @Cadair (see Cadair#6).

Suggest text cleanup

Cadair · 2019-03-18T14:45:41Z

If I understand correctly we are not preventing API changes in minor versions (like with semantic versioning), will 1.2.0 be backwards compatible with 1.0.0?

Correct, this SEP does not specify any policy with regards to API breakages. I plan to write a short document on API breakage policy in the sunpy docs.

I also don't see much of a point of changing versioning number every year, mostly if not big changes are in place.

The information I (after lots of discussion with @rhewett ) want to convey in the version number is the length of support of each release. I am open to any numbering system which does this.

It can, unless forcing updates as the browsers do with pop-ups, the opposite effect on our users, to keep them all not updating for fears to things to break.

From feedback I have seen users already hate how we break stuff where our version number is 0. so I really don't think most people are going to use the version number as a metric for API stability. Also I think that telling a user that if they use a x.0 version it will be supported for a year is a robust statement which is much easier to make than "the 1.y series of releases will be mostly stable, unless we find a major bug, and until we get bored and want to break something at some point in the future". For more on this I would point you at Russ's comments on the previous version of this document: #30 (comment) as he is the one that changed my mind from roughly your perspective.

If we are going to do this we really need to educate our users beyond just this SEP and releases notes. That won't be an easy task.

We need to do this anyway, I don't think there is a universal language of version numbers we can tap into to shortcut this process, Astropy do one thing, pip do another etc etc they all are different and have no real bearing on their (sometimes very strict API policies).

ehsteve

My changes have been incorporated.

rhewett

Up to the decision rationale, this is good enough to proceed

dpshelio · 2019-03-20T15:27:19Z

+is the responsibility of the lead developer to create a release schedule that
+is consistent with these requirement and to present it to the Board at the
+beginning of every year.  Releases are recommended to be timed to pertinent
+release cycles of upstream packages.


And that would be published on the wiki? on the docs? as a new project/PR?
I would prefer we say here where to expect that information, and how long the beginning of the year would take... is that the first week of January? is that before end of February?

Well I would imagine it in reality wont change very often, so I don't think timing is that important. To be honest I think the best canonical reference for the release schedule is this SEP?

Co-Authored-By: Cadair <stuart@cadair.com>

DanRyanIrish · 2019-04-03T17:04:04Z

+## Release Schedule
+
+This SEP prescribes that there will be at least two releases of the sunpy core
+package per year with at least 4 months (preferably 6 months) between these


This could mean that we could have up to an infinite number of releases in a year so long as there are at least four months between the first and last releases. Is this what is meant? If not, is this a loophole that we don't want to exploit in the future? Does this need to be clarified?

I think I have clarified this in the newest commit, can you take a look?

Cadair · 2019-04-05T09:37:09Z

+emitted** when an alternative option exists for the functionality, or the
+functionality is to be completely removed.
+
+All effort will be made to provide at least one LTS release where functionality


This change came out of a conversation with @dpshelio

@nabobalis what's your thoughts on this?

I'd ask someone smarter.

I don't totally get what you mean in the paragraph, basically you pledge to get at least a 2 year deprecation cycle?

Shall we have a time commitment here instead of "one LTS release"? In case the frequency of LTS releases changes...

The purpose of this is to ensure that if any users go from LTS to LTS release they still get a deprecation warning about pending changes. So with the planned release cadence it would be a one year deprecation cycle.

@tiagopereira What do you see as the value in a time based deprecation policy? I think that if the cadence of the LTS releases change then the deprecation time would also want to change along with it, so that as I mentioned people going from LTS to LTS will always get a warning.

I'm not sure if a time-based policy is the way to go. I just wanted to ensure that API changes do not happen very often, in case LTS releases become very frequent. Probably fine to keep the current wording.

The idea of this SEP isn't to overly restrict the ability for us to make API changes, but the idea of an LTS is that you get at least a year of support on that release, so you can opt into slow API changes by sticking on that LTS and then moving onto whatever the current LTS is after a year.

LTS releases become very frequent

By definition they cannot be that frequent, from the practical point of view sunpy is manure enough that no one wants to support multiple releases for years.

@Cadair - I missed the point that LTSes are proposed to be a yearly thing, a minimum ~1-year deprecation seems totally reasonable then.

tiagopereira

Sounds good to me!

tiagopereira · 2019-04-05T19:19:31Z

+emitted** when an alternative option exists for the functionality, or the
+functionality is to be completely removed.
+
+All effort will be made to provide at least one LTS release where functionality


Shall we have a time commitment here instead of "one LTS release"? In case the frequency of LTS releases changes...

Co-Authored-By: Cadair <stuart@cadair.com>

Cadair · 2019-04-15T09:00:57Z

I think I have addressed most of the comments on this so far. I had a chat with @dpshelio about it the other week, so maybe he could review it 😉

dpshelio

Sorry for my late response. 👍

wafels · 2019-05-14T18:19:24Z

What is the rationale for following Astropy? Should this be explicit?

Cadair · 2019-05-14T21:25:31Z

We depend most heavily on astropy, so we generally can make use of new features. We tend to depend on n-1 versions of astropy at the point of release, i.e 3.2 is going to come out around the same time as 1.0 and 1.0 will be >=3.1.

The point of the wording in this is that we should follow upstream releases where it makes sense, which I feel it currently does for astropy.

kreardon · 2019-05-22T18:20:43Z

Under "Deprecations and Documentation" it says that "code will emit deprecation warnings." The term "emit" seems vague (to me). Would it be unwise to more specifically say that such warnings will be passed to the logging system (and at what level - WARNING, INFO)? Just so it's clear how to such warnings should be registered and accessed?

Cadair · 2019-05-23T09:38:39Z

I was using "emit" here to cover issuing a warning using the standard python warnings mechanism (https://docs.python.org/3/library/warnings.html#warnings.warn) this is very configurable, the sunpy logger will log them but you can also convert them to errors at run time (as our tests do) etc. So I don't really want to specify the behaviour here beyond that of "it should be a python warning".

kreardon · 2019-05-23T16:54:05Z

I was using "emit" here to cover issuing a warning using the standard python warnings mechanism (https://docs.python.org/3/library/warnings.html#warnings.warn) this is very configurable, the sunpy logger will log them but you can also convert them to errors at run time (as our tests do) etc. So I don't really want to specify the behaviour here beyond that of "it should be a python warning".

Okay, makes sense. Thanks. Now I know what "emit" means. :)

Cadair · 2019-06-14T20:20:05Z

I have made one change here, the LTS release will be the first yearly release (i.e to match when we actually did 1.0). Also this means we can merge changes from GSOC etc into the short-cycle release and have them out in the wild before the next LTS.

Cadair and others added 7 commits December 13, 2018 18:37

Correct title in SEP 8

bed1e5e

First draft of Attempt 2 at a releasing and versioning SEP

fa4e8a8

Strip out anything about API stability

b543bee

Update SEP-0009.md

de83915

Update SEP-0009.md Update SEP-0009.md

Fix up months in example

d7d4738

Update SEP-0009.md

reflow

4a90ca2

Allow the lead dev to skip a release

df1bc91

ehsteve reviewed Mar 11, 2019

View reviewed changes

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

ehsteve suggested changes Mar 11, 2019

View reviewed changes

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md Outdated

Comment thread SEP-0009.md

Comment thread SEP-0009.md

ehsteve added 2 commits March 12, 2019 10:30

text cleanup

b1e4253

req on publicating releases

648b134

ehsteve and others added 3 commits March 14, 2019 09:54

grammar fix

ac20e91

added resources re-eval clause

ddcdc8a

Merge pull request #6 from ehsteve/cadair/releasing-2

1b70e6a

Suggest text cleanup

ehsteve approved these changes Mar 18, 2019

View reviewed changes

rhewett approved these changes Mar 18, 2019

View reviewed changes

mbobra approved these changes Mar 19, 2019

View reviewed changes

dpshelio reviewed Mar 20, 2019

View reviewed changes

Update SEP-0009.md

e319881

Co-Authored-By: Cadair <stuart@cadair.com>

DanRyanIrish reviewed Apr 3, 2019

View reviewed changes

Cadair added 2 commits April 3, 2019 18:10

Clarify wording

cd93b19

Add a more stringent deprecation policy for LTS to LTS users

cdfc3b0

Cadair commented Apr 5, 2019

View reviewed changes

bsipocz reviewed Apr 5, 2019

View reviewed changes

Comment thread SEP-0009.md

tiagopereira reviewed Apr 5, 2019

View reviewed changes

Apply suggestions from code review

219bb0b

Co-Authored-By: Cadair <stuart@cadair.com>

rhewett approved these changes May 9, 2019

View reviewed changes

dpshelio approved these changes May 14, 2019

View reviewed changes

kreardon approved these changes May 23, 2019

View reviewed changes

Swap the ordering of releases

91dcc4d

Cadair mentioned this pull request Jun 15, 2019

Add a blog post about the planned release schedule sunpy/sunpy.org#171

Merged

SabrinaSavage approved these changes Jun 26, 2019

View reviewed changes

ehsteve merged commit 2ebe0d5 into sunpy:master Jun 26, 2019

Cadair deleted the releasing-2 branch June 26, 2019 17:48

Uh oh!

Uh oh!

Conversation

Cadair commented Jan 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbobra commented Jan 30, 2019

Uh oh!

dpshelio commented Jan 31, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ehsteve commented Mar 12, 2019

Uh oh!

Cadair commented Mar 18, 2019

Uh oh!

ehsteve left a comment

Choose a reason for hiding this comment

Uh oh!

rhewett left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tiagopereira left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cadair commented Apr 15, 2019

Uh oh!

dpshelio left a comment

Choose a reason for hiding this comment

Uh oh!

wafels commented May 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Cadair commented May 14, 2019

Uh oh!

kreardon commented May 22, 2019

Uh oh!

Cadair commented Jan 30, 2019 •

edited

Loading

wafels commented May 14, 2019 •

edited

Loading

Cadair commented May 23, 2019 •

edited

Loading