search

alexellis / derek

Reduce maintainer fatigue by automating GitHub
https://github.com/alexellis/derek/blob/master/USER_GUIDE.md
MIT License
806 stars 72 forks source link

Derek set milestone: current/next #90

Open alexellis opened 5 years ago

alexellis commented 5 years ago

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.

rgee0 commented 5 years ago

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.