One minor shed painting sort of comment: Are we going to accept in all documentation going forward that "bugfix" is a single word? And if so should it be used as such consistently or should "bugfix" as one word and "bug fix" as two words be used in different cases?

One other more general comment: I'm basically fine with using the MAJOR version number for indicating LTS releases. No, it's not semver, but I think it's very clear and explicit. That said, I think if we're going to go this route we should try to have MINOR releases more frequently than every six months. I mean, we could try to sort of guarantee that there would be one "at least" every six months, but I don't think there's any need for a strict schedule either. The six month scheme means there would only ever be at most 3 feature releases after each LTS release. In other words they would only ever get up to X.3.Z--there will never be an advance to X.4.Z or higher. Not that there's really anything terribly wrong with that. But given that one of the original problems stated in the introduction is that people are having to rely for too long on dev versions for new features, why not just put out a feature release any time a reasonably important/useful new feature is ready?

I don't have a strict definition of what qualifies..but so long as new feature is added (new models? new stats functions? new I/O handler?) that isn't strictly tied to other new features that are not yet complete I don't think there needs to be a long delay in making the release. Depending on the time resources of the individual maintainers involved this could be done as frequently as every two weeks. I'm not saying we should always do it that frequently, but it's not necessary to bury a new feature in dev for six months either. The actual process of making a release takes half an hour at the most once the testing indicates sufficient stability.

👍 on more frequent releases as @embray suggests, if feasible.

It seems I was the only voice of dissent on the MAJOR version issue, so I'm happy to go along with the proposal here.

However, should this APE also include recommendations for what affiliated packages should expect regarding backwards compatibility? One of the nice things about semver is that a dependent library can specify that it requires packagename >=1.0, <2.0 and know that they won't have to release a new version if packagename is updated. It seems like affiliated packages should require known good versions, since there is no guarantee that the next astropy release won't break the affiliated package. For example, if both astropy v0.2 and v0.3 are known to work, an affiliated pacakge should require astropy >=0.2, <=0.3. What do people think?

@embray - re: "bugfix" - I've been using "bugfix release" for one word, and "bug fix" as in "the act of fixing a bug". That's just my own style, though, not based on any clear rule... But I'm not sure there's a clear definition here. I'm fine with just about any combination of the two, though - I think the context makes it all pretty clear, regardless.

@astrofrog @embray - note that a couple of discussion threads got clobbered by some of the modifications a made - most notably my suggestion that we push the topic of deprecation and a policy for it to a separate APE, as well as the discussion of whether we should leave 0.4 as-is, and start the clock at that release (I think we're all on the same page there, but I'm not entirely sure, because I think there might have been a typo in one of @astrofrog's comments that changed the meaning).

@astrofrog @embray @mwcraig - thanks for the typo fixes. Clearly I need to remember to run the spell-checker on rst files...

@kbarbary @embray - I'm open to the idea of having more often releases, and could adjust the document accordingly to make it clear that we're just saying six months is the max. The main question then is how to deal with feature freeze. That is, do we say we always have a feature freeze a month before any release? If so, then we might spend a lot of time in feature freeze.

The idea about having these freezes is that we have thus far always had to take at least a few weeks to do the releases, because we want to test them to make sure there are no last-minute problems. So are we going to designate some releases as significant enough to have betas and RCs, but not others? The whole reason I put in that section is so that we don't have to ask that question anymore - the answer is just "always." But if we do a release every few weeks, obviously a 1mo feature freeze/beta won't work.

I see the point that we may want more frequent releases... But I think its a bit more work than just an hour - there's announcements to be made, effort that has to go into updating docs on a new release, making sure the web site is in sync, etc. We can say we're going to be more lax about that on some releases, but then we have to decide which are the "serious" releases.

EDIT: the answer to this could be "the LTS releases", I suppose. I.e., they are the only would bound to the feature freeze schedule. But I'm not sure we want to wait 2 years to be sure that the author/credits list is up to date and such...

@kbarbary - re: affiliated packages and backwards compatibility: this is a good point, but I think maybe it belongs in a separate APE, as its a result of this APE, rather than influencing it directly? Perhaps the one I suggested above about deprecation and when/how it should be done? Or are you saying you think we should make a change to the actual content here to make it easier on affiliated packages?

@eteq re: affiliated packages and backwards compatibility: I mainly wanted to point out this direct result of never guaranteeing any backwards compatibility (the result being that any affiliated package has to re-release with every new astropy release), to make sure that is acceptable to everyone (particularly affiliated package authors!). But perhaps I'm just complaining more about non-backwards-compatibility, which I said I wouldn't do. :)

I don't think this should go in a separate APE as it isn't a proposal to change astropy in any way. Rather, it is a guideline on how to use astropy given this APE. So I guess it should simply go in the docs about affiliated packages once this APE is accepted.

I'd like to also say I very much like the idea that we say we won't allow more than 6 months to go (approximately) before the next non-bugfix release. I think there will be occasions where we want to get a new capability out there when it is ready and not be artificially constrained to wait until the next 6 month interval is over. In such cases I don't think the one month freeze issue applies. We only need worry about freezing at a specific date is when we are forced to because we don't want to go past the 6 month interval. It is irrelevant if we haven't. We just release when it is judged ready to (though that does mean starting to freeze other features from getting in while we are starting to prepare for the relase).

@kbarbary - Ah, I see what you're saying now. In my mind, the idea is that while we aren't guaranteeing backwards compatibility for the package as a whole, any given piece may be very stable. For example, I think you're safe assuming that astropy.io.fits.open will work in many future versions. So a package that only uses that part of astropy can probably get away with saying just astropy>=0.1 . But an affiliated package using some esoteric bit of astropy.modeling right now should probably say "astropy>=0.3, <0.4", because a lot of things will probably change between the two.

I realize this is basically just saying "well, it depends", but I don't really know that there's a better answer :/ I just don't think we're in a position to promise any permanent backwards compatibility (and maybe never will be).

@perrygreenfield - I see your point, but then we have an uncertainty about whether or not we need a feature freeze/beta/RC/heavy advertising. And the discussion surrounding that could easily take quite a bit of time/effort.

But these comments lead me to an alternative. What if we say this:

• If we want a new feature release, and it's less than 5 months since the previous release, we immediately do an RC, and if all goes well for that version, we release after a week of the RC getting tested (if more RCs are needed due to bugs, another week per RC). This gets advertised on our mailing lists (astropy-dev, astropy, and maybe scipy and python-announce) and twitter, but not more extensively unless there's a specific reason.
• If 5 months (+/- a few weeks if something big is imminent) has passed without a release, it automatically triggers a beta/RC/release as described in the document.

@astrofrog @embray @perrygreenfield @kbarbary - how does that sound? If it sounds good, I can update the APE to put this in cleaner language.

I think you're safe assuming that astropy.io.fits.open will work in many future versions

Yes, it will continue to work for a long time. Though as a somewhat glib aside I would like to point out my dream is that one day users will just do Image.from_file('foo.fits') and never, ever have to care about the fact that it's a FITS file. It's a longshot, but I can dream...

We discussed this APE at the developer hangout today and came to the conclusion that we should leave this mostly as-is in terms of the 6-months cycle, but with loosening of the language to say that we can do a release sooner than 6 months if there's strong agreement to do so. The general sense seemed to be this probably wouldn't happen too often, so it wasn't worth worrying about it too terribly much.

I will update this appropriately later today and send out a final request for comments on astropy-dev. If there are no major changes we'll plan on accepting it by next week.

Alright, I just pushed up a change that integrated feedback from @embray and @astrofrog, mainly dealing with the faster-than-six-months description (it got moved to its own sub-section)

👍

Alright, seeing as how it's "next week" and there have been no comments on-list since my last announcement, I think this is all-set. I'll merge it now and update it's status to "accepted"

Thanks for all your feedback - definitely makes it better!