Publish a release calendar

[joostschouppe]

Description

I made some updates to the ELI a while back, in hopes it would be live before the old links would die. Unfortunately, that's not the case, so the default imagery for Flanders now returns a blank. I find myself wondering when the next iD release is going to be, so I'd know when to expect the issue to be fixed. I looked around but can't seem to find this info.

I guess a better solution would be to decouple iD releases from the frequent ELI updates, but that's probably a much bigger deal then documenting when you can likely expect an update. Having an idea of this could also have other uses. The suggestion assumes this is predictable or plan-able at all of course.

[1ec5]

The community index is also affected by the release schedule: #9706.

[bhousel]

I guess a better solution would be to decouple iD releases from the frequent ELI updates, but that's probably a much bigger deal then documenting when you can likely expect an update. Having an idea of this could also have other uses. The suggestion assumes this is predictable or plan-able at all of course.

This was #7428 / #7425. It was the right thing to do in 2020, and it's still the right thing to do in 2023.

[danieldegroot2]

Currently no changes to this dependency are documented for the next major release of iD, 2.26.0. Same for 2.25.0 (released March 2023). The last major update with documentation of such a change in dependencies was 2.24.0, not counting id-tagging-schema (released January 2023). Tyrasd has been the maintainer for both. (such changes were usually documented with major changes in the past.)
https://github.com/openstreetmap/iD/blob/bb76e68438e0d1bd6845a84ac3bfd4f1d0bb204e/CHANGELOG.md#hammer-development

cc: @tyrasd could you clarify the recent change in documentation, please? Is it only as bhousel refered to above?

[nickrsan]

I agree with this request - I think a release calendar, a predictable release pattern, or continuous delivery (which I imagine would take some work to get to, given the docs) would go a long way to supporting the health of both the data getting entered with iD, but also iD itself. Ideally, this would be tied to a roadmap so that contributors could see what maintainer priorities are and target pull requests that support those priorities, where possible, knowing they'd be more likely to get reviewed and accepted in a timely manner. I think those two things would encourage additional participation in the project.

[nickrsan]

I'm thinking this thread likely better belongs as a discussion thread - there's no specific endpoint to implement in software, but I think it's an important topic that we should raise with Martin (@tyrasd) at the community meetings, in addition to further discussion here. I'm converting it to a discussion now, but if any of the maintainers/people with higher repository permissions disagree with that decision, feel free to convert it back.