I think the usual approach is to use milestones for tracking versions and distribute issues to those and projects to track a "big feature" which is composed of many individual tasks. The other difference is that projects allow to create "cards" (like sticky notes) which can be later converted (or not) to issues.
As an (arbitrary) example, this how Zephyr uses it. Milestones: https://github.com/zephyrproject-rtos/zephyr/milestones Projects: https://github.com/zephyrproject-rtos/zephyr/projects Example milestone: https://github.com/zephyrproject-rtos/zephyr/milestone/41 Example project: https://github.com/zephyrproject-rtos/zephyr/projects/24 I can create a 10.0 milestone with due date October 1st for the time being. We can use this to organize issues as being aimed to be included to 10.0 or to be for a later version (no milestone set). The project board can be used for example for high-level ideas which are not yet tangible as a more detailed issue (such as those right now on the "roadmap" project) or for groups of tasks to be done related to a larger effort. Best, Matias On Fri, Aug 14, 2020, at 18:39, Abdelatif Guettouche wrote: > We've already agreed on the version numbering. It's pretty much the > same as it was + the patch number. So if there is incompatible change > to the APIs, we need to bump the major number to 10. > > > wouldn't you like to create a milestone for next version as well? > > We used Github Project last time to track PRs and triage them for the > release notes. > I'm not sure how Milestones would work here. We can give a shot if > you have a clear vision. Can we use both Project and Milestones, they > don't seem to be mutually exclusive. > > On Fri, Aug 14, 2020 at 8:54 PM Nathan Hartman <hartman.nat...@gmail.com> > wrote: > > > > On Fri, Aug 14, 2020 at 2:51 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > > > > Nathan started this here: > > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 > > > > > > > > I would say let's fill that out, we can change it to 10.0 later. I > > > > will kick off getting the tracking board and the PR changes going in > > > > next week, that I thought worked quite well for realtime and async > > > > collaboration last time. > > > Done > > > > > Thanks for documenting the wdog changes. My computer blew up recently and I > > was stuck with only mobile for a week so I've been playing catch-up... > > > > In terms of how to do our version numbering, ASF doesn't dictate any > > policies about that AFAIK. Those sorts of technical decisions are left up > > to the individual projects. I agree with semantic versioning and I think we > > should bump the major version number to 10 given the recent breaking > > changes to APIs. > > > > Nathan >
