You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you can probably tell, I've been investigating/thinking about this.
I think if this was to work there'd have to be disciplined in the creation of milestones with sensible due dates. That way we could build a timeline using due_on to find which milestone we are currently working towards and the next one after that. This would shift the burden to creating the milestones where it would be once per milestone, rather than once per set milestone.
Alternatively could we work off release levels? Make current and next increments on the latest release, so if we're on 0.7.4 as a release then current would be 0.7.5 and next 0.7.6
From what I can tell Derek will only set milestones that already exist, so in taking the first approach we could fall off the cliff if the timeline runs out of values. I wonder if a Derek create milestone: <major|minor><date> might be useful. It would find the latest, do the necessary arithmetic and create an appropriate milestone the a end date. Or we could use a release hook and then create a milestone that is n more than the hooked release - given we're looking at current and next n would be two.
We might also catch the release and use the version to delete the associated milestone.
Needs more thought - but I can't always remember what milestone number to pick when doing this on mobile for instance.
Derek set milestone: 0.5.4
vs:
Derek set milestone: next
Which could be: 0.5.5
Derek add milestone
-> Might just add the latest one available.There are other tools that can generate change logs but this seems like a simple feature to explore more.
The text was updated successfully, but these errors were encountered: