APE 21: APE on ending long term support releases + Updates to APE 2 to reflect new release cycle without LTS

[astrofrog]

This is a draft and not ready for review - it follows the related discussion on astropy-dev. If you are interested in joining as a co-author please ping me!

• [x] Rename file to APE_21.rst

EDIT: Close #20

[taldcroft]

I agree with the points from @nstarman and @WilliamJamieson above, which I believe are also in agreement with the summary of the Coordination meeting outcome from @eteq.

@saimn - are you OK with the yearly major release? If so it seems like we would have achieved consensus, with the caveat that @astrofrog needs to update the APE's to reflect one year instead of two between major releases.

[astrofrog]

I've now tried to implement the 'consensus' from the coordination meeting into these documents. The bottom line as far as I have understood is that we are basically following semantic versioning, and specifying that one year is the minimum time between major releases, six months is the default and a maximum time between non-bugfix releases, and deprecations have to be in releases for at least a year before changes are carried out.

@taldcroft @WilliamJamieson @nstarman @pllim @saimn @mhvk @eteq - could you take a look at the latest versions and leave comments/suggestions or approve if you are happy with the APEs as-is? (just to see if we are getting close to consensus)

[weaverba137]

I re-read both APEs and they sound good to me. Thanx for the reminder!

[saimn]

specifying that one year is the minimum time between major releases

If one year between major releases is a minimum, then I agree, but that was not my understanding from the above (every major release is yearly).

That was also my point earlier in the discussion (https://github.com/astropy/astropy-APEs/pull/82#discussion_r1115566239), we just need to keep some flexibility on when we want to make a major release. It will depend on how many deprecated items we have accumulated. And if there is some new feature that is waiting for the end of the (1 year) deprecation period, we can wait 6 months more before releasing the next major version. But most of time we are just deprecating old functions or some renamed arguments and there is no urgency in removing those.

Also we will need a way to track the things that have been deprecated to know when they can be removed, and when we decide that next version will be a major one.

[astrofrog]

I thought the consensus was that it was a minimum as @eteq said:

need to clarify that the semantic step happens only if there are any pending->post-deprecaton

[pllim]

How many approvals are needed here? How should we proceed? Thanks!

[astrofrog]

My understanding is that APE 0 makes it the responsibility of the CoCo to accept/reject APEs - the main purpose of 'approvals' here is just to see how many people are broadly on board with this but it's not like there is a 'minimum' number of approvals needed. I've asked for comments by the end of the week - if there are no objections by then and no further changes, we can hand over to the CoCo to decide how to proceed.

[pllim]

Thank you for the approval! Should we put the final date stamp and status on this PR and merge?

[hamogu]

This has been approved by the Coco through the approvals here and internal Coco communication by those Coco members that did not comment here. I will go through the process of merging and try publishing on Zenodo etc. later today (if zenodo let's me - their webinterface has been flaky recently, if not, I might have to re-try in the next few days).

[astrofrog]

Thank you to everyone who contributed and to the CoCo for approving!