LGM-Doyle wrote: ↑Mon Dec 04, 2017 7:55 pmCould we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.
</EDIT>Vezzra wrote: ↑Fri Dec 08, 2017 12:53 pmWhile I understand and agree that's an issue, how is renaming those milestones to something more generic supposed to solve anything? Once the release is out, I intend to rename "0.4.8 (optional)" instead of making a new milestone and moving all the assigned issues and PRs anyway, so unless the timestamp of issues/PRs are reset when the assigned milestone is just renamed, there shouldn't be a problem with those. And the issues/PRs assigned to "post 0.4.8" will have to be reassigned to the renamed "0.4.8 (optional)", so their timestamp is going to change regardless how "post 0.4.8" has been named...?Could we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.
Vezzra, mass changing of milestones causing spurious timestamping is more irksome than a full blown issue.
This might work, but most other re-labelings, reset the timestamp. We will see.Vezzra wrote: I intend to rename "0.4.8 (optional)"
Milestone names could be choosen that do not require immediately moving many/any issues upon releasing a new version.Vezzra wrote:how is renaming those milestones to something more generic supposed to solve anything?
The current milestones are "v0.4.8 (manadatory)", "v0.4.8 (optional)" and "post 0.4.8".
One way of interpreting their intent is immediate, near future and far future requirements. Releasing v0.4.8 will not immediately make all of "v0.4.8 (optional)" mandatory for the next version. The version numbers could be stripped from the second two milestones. It would improve their utility.
Looked at another way the current milestones correspond loosely to blockers, non-blockers and feature requests.
And in another way, required, desirable, and wished for.
We need a milestone for blocking issues and required features of the next release version. We could name it "vX.Y.Z".
We need a milestone for non-blocking issues, implemented but non-required features and upcoming requested features. We could name it "optional"
We need a milestone for long term works in progress (WIP) and wished for feature requests. We could name it "wishlist.
If we used milestone names like "vX.Y.Z", "optional" and "wishlist, then after release a new milestone named "vX.Y+1.Z" would be created to which a single feature request is moved from "optional. Otherwise nothing would change.