Move to a time based release cycle.
- Dominant language
- No language data
- Stars
- 39
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
What the title says. As Ross describes on the mailing list (https://groups.google.com/forum/#!topic/ckan-global-user-group/IZALBiqajOs):
"Currently releases are based on features + resources. That is when there are enough features baked in, and when the resources are available to perform the release-process. It’s entirely possible that this is something that makes CKAN an undesirable project to contribute to as a developer because you have no idea when/if your contributions will make it into an official release.
This leaves developers with only 3 options:
1. Suffer any bugs in core that affect you and wait for a point release.
2. Maintain your own patches, submit them, but have to manage them yourself until an official release in the future.
3. Maintain your own semi-fork of CKAN.
A better way to do releases would be to decide how many will be released in a year, and set a schedule - for instance, there will be a release of CKAN every 6 months, with a point release in between. This way developers can contribute to core and know _exactly_ when their changes will be available - allowing them to manage expectations with their customer/client/boss. This will obviously require the allocation of resources."
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.